zfs replace
実家に置いてあるサーバは6TBのハードディスク4台でFreeBSDのzfsでraidzを組んでいるのですが、
しばらく前から1台がエラーを出すようになっていたので同容量の新しいディスクを買って入れ替えました。
hot swapには対応していないハードなので電源落として入れ替えてから zpool replace するだけですが、
resilverに3日近くかかるのか…。
AMD Turion II Neo N54L Dual-Core という大昔の遅いCPU（むかし流行したHP Microserver）なのが原因ですかね。
motoyuki% zpool status -v
pool: zdata
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Tue Nov 1 23:09:18 2022
1.98T scanned at 62.1M/s, 1.49T issued at 46.7M/s, 9.94T total
363G resilvered, 14.94% done, 2 days 04:46:54 to go
config:
NAME STATE READ WRITE CKSUM
zdata DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
diskid/DISK-WD-WX61D68AARTA ONLINE 0 0 0
replacing-1 DEGRADED 0 0 0
15225623215183088814 UNAVAIL 0 0 0 was /dev/diskid/DISK-WD-WX51D583K0PC
ada2 ONLINE 0 0 0 (resilvering)
diskid/DISK-WD-WX51D68AP748 ONLINE 0 0 0
diskid/DISK-WD-WX61D686F8F2 ONLINE 0 0 0
errors: No known data errors
FreeBSDでif_ipsec(4)を使う
policy based VPN
FreeBSDの従来のIPsecの実装では、 setkey(8) でkernel内のセキュリティデータベース(SAD)を操作し、 kernelは送受信するパケットがこのSADに一致する場合は、 SADに従ってパケットの行き先を決めて暗号化の処理を行なっています。
ルーティングテーブルの参照はこれらの処理の後に行われます。つまり、
- IPsecで通信するパケットはSADで行き先が決まる。
- それ以外の通常のパケットはルーティングテーブルによって行き先が決まる。
ということになります。FreeBSDハンドブックのIPsecの項目 ( 第14章 セキュリティ | FreeBSD Documentation Portal ) など多くの説明で gif(4) を使ってVPN over IPsecを構築するように書いてあるため、 こうした特徴が分かりにくくなってしまいます。 実際にはgif(4)を設定する必要はありません。
こうやってIPsecを設定して構築したVPNをpolicy-based VPNと言います。
if_ipsec(4)
FreeBSD 11で導入された if_ipsec(4) は、IPsecでroute-based VPNが実現できます。ipsecという仮想的な トンネルインターフェースを作り、そこを通るパケットがIPsecで暗号化されます。 この方法にはいくつかの利点があります。
複数拠点を網目状に結んでIPsecで暗号化された通信を行う場合には、 route-based VPNは便利です。 一つのIPsecトンネルがトラブルで切断されても、動的なルーティングを行なっていれば 他の拠点を経由した通信に自動的に切り替わります。
実際の設定
- FreeBSDサーバ
- 拠点A
- 拠点B
FreeBSDサーバから拠点Aとの間にover IPv4なIPsec VPNを、 拠点Bとの間にover IPv6なIPsec VPNを構築することとします。
# ifconfig ipsec0 create reqid 100 # ifconfig ipsec0 inet tunnel XXX.XXX.XXX.XXX AAA.AAA.AAA.AAA # ifconfig ipsec0 inet 192.168.1.1/24 192.168.11.1 # ifconfig ipsec1 create reqid 200 # ifconfig ipsec1 inet6 tunnel XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA # ifconfig ipsec1 inet 192.168.1.1/24 192.168.12.1
reqidには0以外の整数を指定します。複数のipsecインターフェースを使う場合は 別の数字を指定してください。対向するルータと同じ数字を指定する必要はありません。
/etc/rc.confには以下のように記述します。
cloned_interfaces="ipsec0 ipsec1" ifconfig_ipsec0="reqid 100" ifconfig_ipsec0_alias0="inet tunnel XXX.XXX.XXX.XXX AAA.AAA.AAA.AAA" ifconfig_ipsec0_alias1="inet 192.168.1.1/24 192.168.11.1" ifconfig_ipsec1="reqid 200" ifconfig_ipsec1_ipv6="inet6 tunnel XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX BBBB:BBBB:BBBB:BBBB:BBBB:BBBB:BBBB:BBBB" ifconfig_ipsec1_alias0="inet 192.168.1.1/24 192.168.12.1"
if_ipsec(4) のマニュアルではIPsec通信の鍵を setkey(8) で固定した鍵に設定する説明になっていますが、racoonを使って 動的に鍵を交換することにします。
ということで、次回はracoonの設定をします。
NVR700WとIPsec
2回続けて書いたフレッツ光ネクストと小型ONUの話のおまけ。
NVR510が使えない
YAMAHAのルータで小型ONUに対応した機種は2つ、 NVR510 と NVR700W がある。 後者はSIMが内蔵できてdocomo/au/softbankの3G/4G網につなぐ機能がありずっと高価なので 最初NVR510を調達したのだけど、設定してみるとIPsecなトンネルには対応していないのでした。 NVR510/NVR700Wのコマンドリファレンス の記述みて誤解していました。
他にもport分割なVLANが使えないなど機能的に不満があったので、予備にとってあった NVR700Wを投入してNVR510を予備に回すことにした。
FreeBSD 13.0のIPsec
FreeBSD 13.0-RELEASE Release Notes | The FreeBSD Project より
Removed support for IPsec algorithms deprecated by RFC 8221 as well as Triple DES. 16aabb761c0a (Sponsored by Chelsio Communications)
ということでFreeBSD 13.0ではIPsecでの3DESサポートが削除された。 FreeBSDサーバと対向して使っているYAMAHAルータのIPsecの設定も3DESからAESに 書き換えることにした。
FreeBSDのports/security/ipsec-toolsでインストールしたracoonの設定ファイル /usr/local/etc/racoon/racoon.confで、
encryption_algorithm 3des;
となっている行をすべて
encryption_algorithm aes;
に変更してracoon立ち上げ直し。
NVR700Wがaes256-cbcに対応していない
NVR700Wのコマンドリファレンスマニュアルで IPsec ike encryption の項目を読むと、IPsecの設定では同じAESでも暗号強度の違いでaes256-cbc, aes192-cbc, aes-cbcの 3種類がある。一番暗号強度が強いaes256-cbcを指定して設定してみたところ、
のIPsecトンネルは上がってくるのだけど
のIPsecトンネルは上がってこない。いろいろ試してみるところ、
NVR700Wはaes256-cbcだと通信できないようでした。マニュアルの嘘つき。
RTX700Wと対向するIPsecトンネルはaes-cbcを指定するよう変更して解決。
FreeBSDのracoon.confではいずれの場合も
encryption_algorithm aes;
で大丈夫。
YAMAHAルータのIPsecとNAT-T設定を巡る不思議
YAMAHAのサイトにある IPsec設定ガイド を参考に、ルータの外向けIPv4固定グローバルアドレスがXXX.XXX.XXX.XXX、 対向するルータのIPv4アドレスがYYY.YYY.YYY.YYY、 LAN側の内側IPv4アドレスが192.168.0.1のとき、IPsecトンネルは
tunnel select 2 ipsec tunnel 102 ipsec sa policy 102 2 aes-cbc sha-hmac ipsec ike version 2 1 ipsec ike encryption 2 aes-cbc ipsec ike local address 2 192.168.0.1 ipsec ike local id 2 XXX.XXX.XXX.XXX ipsec ike pre-shared key KEYSTRING ipsec ike remote address 2 YYY.YYY.YYY.YYY tunnel enable 2 nat desciptor type 1 masquerade nat descriptor masquerade static 1 1 192.168.0.1 esp nat descriptor masquerade static 1 2 192.168.0.1 udp 500
のように書くことができる。YAMAHAルータ側のアドレスはNATの中の192.168.0.1だけれど、 これで（IPsecでNATに対応するための）NAT-Tを指定しなくても通信ができていた。
ところが対向がFreeBSD 13.0サーバの場合、YAMAHAルータで192.168.0.1というローカルアドレスを 使用しているのを検知してしまうのか、racoon.confの中で nat_traversal off; を指定しないとこの設定のYAMAHAルータとの間でトンネルを確立できなくなってしまった。
詳しいところはまだ調べていないけれど、参考まで。
FreeBSDルータと対向するYAMAHAの設定
前述したように、FreeBSDルータとRTX1200であれば aes-cbc ではなく aes256-cbc が指定可能。
tunnel select 2 ipsec tunnel 102 ipsec sa policy 102 2 esp aes-cbc sha-hmac ipsec ike version 2 1 ipsec ike always-on 2 on ipsec ike encryption 2 aes-cbc ipsec ike group 2 modp1024 ipsec ike hash 2 sha ipsec ike keepalive log 2 on ipsec ike keepalive use 2 auto heartbeat ipsec ike local address 2 192.168.0.1 ipsec ike local id 2 XXX.XXX.XXX.XXX ipsec ike log 2 key-info message-info payload-info ipsec ike negotiate-strictly 2 off ipsec ike pfs 2 on ipsec ike pre-shared-key 2 KEYSTRING ipsec ike remote address 2 YYY.YYY.YYY.YYY ipsec ike remote id 2 YYY.YYY.YYY.YYY ip tunnel mtu 1280 tunnel enable 2 nat desciptor type 1 masquerade nat descriptor masquerade static 1 1 192.168.0.1 esp nat descriptor masquerade static 1 2 192.168.0.1 udp 500
FreeBSDサーバ側
FreeBSDルータ側のIPv4ローカルアドレスが192.168.1.1/24、YAMAHA側が192.168.0.1/24とする。
/usr/local/etc/racoon/racoon.conf
remote XXX.XXX.XXX.XXX[500] {
exchange_mode main,aggressive;
doi ipsec_doi;
nonce_size 16;
lifetime time 28800 sec;
initial_contact on;
situation identity_only;
my_identifier address "YYY.YYY.YYY.YYY";
peers_identifier address "YYY.YYY.YYY.YYY";
mode_cfg on;
generate_policy on;
nat_traversal off;
ike_frag on;
passive off;
support_proxy on;
proposal_check obey;
proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
sainfo address 192.168.1.0/24 any address 192.168.0.0/24 any {
pfs_group 2;
lifetime time 28800 sec;
encryption_algorithm aes;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
sainfo address YYY.YYY.YYY.YYY any address XXX.XXX.XXX.XXX any {
pfs_group 2;
lifetime time 28800 sec;
encryption_algorithm aes;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
/usr/local/etc/racoon/psk.txt
XXX.XXX.XXX.XXX KEYSTRING
/etc/ipsec.conf
flush; spdflush; spdadd 192.168.1.0/24 192.168.0.0/24 any -P out ipsec esp/tunnel/YYY.YYY.YYY.YYY-XXX.XXX.XXX.XXX/require; spdadd 192.168.0.0/24 192.168.1.0/24 any -P in ipsec esp/tunnel/XXX.XXX.XXX.XXX-YYY.YYY.YYY.YYY/require;
フレッツ光ネクスト ギガファミリーと小型ONUへの切り替え (続)
前回 フレッツ光ネクスト ギガファミリーと小型ONUへの切り替え - Motoyuki's blog の続き。
工事終了
6/19(土) 午前中の工事予定だけど、早朝のうちに局内工事が行われたらしい。RTX810のsyslogを読むと
2021/06/19 05:09:19: PPPOE[01] Disconnected, cause [No error.] 2021/06/19 05:09:19: PPPOE[02] Disconnected, cause [No error.] 2021/06/19 05:09:19: PPPOE[01] Connecting to PPPoE server 2021/06/19 05:09:19: PPPOE[02] Connecting to PPPoE server 2021/06/19 05:10:16: PPPOE[02] Disconnected, cause [PPPoE: PADI Timeout] 2021/06/19 05:12:28: PPPOE[01] Disconnected, cause [PPPoE: PADR Timeout] [snip] 2021/06/19 05:22:52: PPPOE[02] Connecting to PPPoE server 2021/06/19 05:23:08: PPPOE[01] Connecting to PPPoE server 2021/06/19 05:23:49: PPPOE[02] Disconnected, cause [PPPoE: PADI Timeout] 2021/06/19 05:24:05: PPPOE[01] Disconnected, cause [PPPoE: PADI Timeout] 2021/06/19 05:24:07: PPPOE[01] Connecting to PPPoE server 2021/06/19 05:24:28: PPPOE[01] PPPoE Connect 2021/06/19 05:24:28: PP[01] PPP/IPCP up (Local: XXX.XXX.XXX.XXX, Remote: YYY.YYY.YYY.YYY) 2021/06/19 05:24:48: PPPOE[02] Connecting to PPPoE server 2021/06/19 05:24:48: PPPOE[02] PPPoE Connect 2021/06/19 05:24:48: PP[02] PPP/IPV6CP up
なので朝5時過ぎの15分程度だったようだ。設定そのままでスピードが増速されていることを確認。
GE-PON-ONUから光コンセントを外す
ということで、既に届いている小型ONUに切り替える作業を開始。
これまで使っていた三菱電機製の GE-PON-ONU タイプD<1>2 の底面部をこじ開ける。
これが非常に硬くてかなりの力が必要。開けるとこんな感じ。光コンセントは簡単に外すことができる。
小型ONUの取り付け
YAMAHAのNVR700Wに小型ONUを取り付けて、GE-PON-ONUから外した光コンセントを挿入しておしまい。
あとはこれまでYAMAHA RTX810で使っていたconfigurationをNVR700Wに流し込めばおしまい、のはず だったけれど、いくつかトラブルがあったのでこの話はまだ続く。
フレッツ光ネクスト ギガファミリーと小型ONUへの切り替え
最近のYAMAHAのルータ NVR510とNVR700Wは小型ONU（ONUは光ファイバーの信号を電気信号に変換する装置で光回線終端装置ともいう）の内蔵に対応していて、単体のONUと比べると筐体が一つ減る利点がある。
実家のネットワークはフレッツ光ネクスト ファミリーハイスピードタイプという下り200M、上り100Mのサービスを利用してきたのだが、調べてみると上り下りとも1Gのギガファミリータイプの対応地域になっているので、増速のタイプ変更とともに小型ONUへの交換をお願いしてみることにした。
最近のNTT東日本の申し込みは基本的にWeb上で完結するようになっているけれど、申し来み画面には「小型ONUへの変更希望」という項目はないし、小型ONUで検索して見つけた先人たちの体験記をみても電話するしか方法がないようなので、仕事の合間に暇を見つけて窓口に電話してみた。
平日の14時過ぎ、10分弱待たされてやっと電話が通じた。ギガファミリーへの変更希望と伝えると、既存の契約の契約番号、住所、契約者氏名、そして料金引き落としの銀行名を聞かれて確認（銀行名で確認するのは興味深かった）された後、変更は可能との返事。そこで小型ONUへの変更希望を伝えると、なんと「ギガファミリータイプは小型ONUに対応していません」とのこと。
「御社のページで対応していると書いてありますけど」と伝えると「どのページですか」と聞かれたので「小型ONU NTT東日本」で検索して出てくるNTT東日本のニュースリリースの ページのことを伝えた。
お調べしますと言われてこちらの電話番号を伝えていったん電話を切った。
30分ちょっとでコールがあって、ギガファミリータイプでも対応していますとのこと。
- 使用中のONUから光コンセントを抜いて、別途送付する小型ONUに差し替えるだけ。
- 小型ONUは今週末に届けるので、工事終了後は古いONUを返送。
- 局内工事のみ。費用2,200円。
- 局内で工事が終わるとギガファミリータイプへの変更がされて自動的に増速。
- 工事開始や終了の連絡は特にないらしい。
これだけなら私がいない時間帯でも大丈夫そうだけど、私が現地にいたほうがいい前提らしいのと、トラブルがあったときの対処のためにも私が一日実家に行ける週末の土曜日を工事日に指定。
ということで、この話は続く、はず。
今更ながら HP Proliant Microserver Gen7 を使う
個人的にまだ何台か使っているのでメモ。
ハードウェア
メモリは DDR3 PC3-10600 ECC DIMM 4GB x 2 で計 8GB が最大とされているけれど、 ECC なしの DDR PC3-12800 DIM 8GB x 2 で計 16GB でも大丈夫。但し相性問題があるらしく認識しないメモリもある。
非力な CPU のサーバだけどメモリ 16GB だといろいろ使えて便利。
remote access card
firmware
最新の firmware 1.4 はここ : https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_d9b60d684ae24ba5a15a951389&swEnvOid=4168
java 設定
https://www.java.com/ja/download/ から最新の JAVA JRE (執筆時点で Version 8 Update 211) を入手してインストール。
「コントロールパネル → JAVA → セキュリティ → 例外サイト」に remote access card の URL を登録。
最近の JAVA は remote access card の KVM の通信で使われる暗号に対応しなくなったので、 C:\Program Files (x86)\Java\jre1.8.0_211\lib\security\java.security をメモ帳で開いて
#jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
# EC keySize < 224, 3DES_EDE_CBC, anon, NULL
の2行をコメントアウト。
ブラウザ対応
remote access card は Microsoft Edge や Internet Explorer では普通にアクセスできるけれど、 Firefox ではログイン画面から先に進めないという不具合があった。
Firefox のプライベートウィンドウからアクセスするとこの問題を回避できる。
OS 対応
Windows 10
Windows 10 では Radeon HD4200 のサポートが終了していて、 legacy ドライバをインストールしても 標準ドライバで上書きされてしまう。ややトリッキーな方法で対処することもできるみたいだけど、 リモートからアクセスしない用途で使うので放置。
おまけ
Windows でランダムに生成される IPV6 アドレスの使用を止めるには、
netsh interface ipv6 set global randomizeidentifiers=disabled
EUI-64で生成される固定したアドレスにしておかないと外からアクセするのに不便。
