みなさん、こんにちは。
先日、28年連れ添った hi-ho の PPPoE 接続に見切りをつけ、IPv6 IPoE への移行を決意したところまでをお話ししました。
あれからおよそ一週間。hi-ho から届いた「開通」の通知を皮切りに、実は私の仕事場のネットワーク構築は、当初の予定を大きく上回る「機材リプレイス」と「仕様の罠」に翻弄されることとなりました。
今回は、前回の宿題となっていた検証結果と共に、ヤマハの名機 NVR500 との決別、そして後継機 RTX1210 導入によって得られたもの、それと引き換えに失ったものについての記録を綴りたいと思います。
前回の宿題：
- NVR500 で IPv6 プレフィックス取得設定ができるか
mirrorselectの速度はどこまで改善するか- Cloudflare への
curlは無事に通るようになるのか - 全体の体感速度の変化
NVR500との別れ
【宿題1】NVR500によるIPv6プレフィックス取得の試行
まず、私が最もこだわっていた「NVR500 で完結させる」という挑戦についてです。 結論から言えば、NVR500でのIPv6開通は、無残なエラーとともに幕を閉じました。
hi-ho の IPoE サービス（OCNバーチャルコネクト）が有効になった後、NVR500 に以下のコマンドを流し込み、LAN 内に IPv6 を導こうと試みました。
NVR500 で試した IPv6 設定メモ
ipv6 routing on ipv6 lan2 address dhcp ipv6 lan2 dhcp service client ir=on ipv6 lan1 address ra-prefix@lan2::1/64 ipv6 lan1 rtadv send 1 o_flag=on ipv6 lan1 dhcp service server
しかし、ここで大きな問題に直面します。エラーが出てコマンドが完結しないのです。
show ipv6 route コマンドでWAN側（lan2）を確認すると、確かに IPv6 アドレス自体は取得できています。ここまではいい。しかし、そこから先に進めない。IPv6 接続（IPoE）を確立し、さらに IPv4 通信をカプセル化して流す必要があるのですが、NVR500 にはその術（仕様上の対応）がそもそも存在しなかったのです。
実は、これが同じ IPoE でも「v6プラス」のような標準的な MAP-E サービスであれば、有志が公開している計算スクリプトなどを参考に CLI から無理やり設定して延命できた可能性もありました。しかし、OCNバーチャルコネクトはポート計算のロジックが独自で、NVR500 の古いコマンド体系ではどうあがいても対応できませんでした。
「アドレスは見えているのに、道が繋がらない」
愛着ある名機が、現代の IPoE（OCNバーチャルコネクト）という仕様の前で立ち尽くしているのを見て、私はついに NVR500 との別れを決意しました。
「今までありがとう、NVR500。君は最高のルーターだったよ。」
RTX1210 の導入と「パスワード不要」の衝撃
NVR500 を断念した私が次に手にしたのは、ビジネスルーターの定番 RTX1210 です。
今回は予算を抑えるため中古市場を探索。結果、「通電のみ確認」という個体を相場より2割ほど安くゲットできました。
届いた個体は、管理画面にもすんなりアクセスできる完全な正常品！さっそく、運命の IPoE 設定に取り掛かります。
儀式の終わり
RTX1210 を設置し、GUI（かんたん設定）から「OCNバーチャルコネクト」を選択。 ここで驚いたのは、接続 ID もパスワードも一切入力することなく、設定完了ボタンを押した数秒後には「接続中」に変わったことです。
長年「PPPoE 認証」をネットワーク開通の神聖な儀式としてきた身からすると、あまりにも呆気ない幕切れ。しかし、その恩恵は数字として如実に現れます。
期待と現実、IPoE 環境の実測検証
RTX1210 導入後、前回の「宿題」の実測を行いました。
【宿題2】mirrorselect の速度計測
平日の 16 時台に計測。結果は……期待したほど劇的な改善は見られませんでした。
$ mirrorselect -c jp -m 10 -a amd64
1. 8.12 Mbps http://linux.yz.yamagata-u.ac.jp
2. 0 b/s http://mirror.hashy0917.net
3. 4.64 Mbps https://linux.yz.yamagata-u.ac.jp
10 箇所中 3 箇所でタイムアウトが発生。IPoE 化ですべてが爆速になるわけではなく、サーバー側の帯域制限や、回線の出口側の混雑に左右される現実を突きつけられました。回線が混んでいない時間帯ならもちろん違った結果になりますが、爆速を期待していただけに少し残念な結果でした。
【宿題3】Cloudflare への curl 計測
驚いたことに、Cloudflare への curl テストは依然として「通らない」という謎が続いています。
$ curl -4 -o /dev/null https://speed.cloudflare.com
# ... 0 b/s のまま沈黙
やはり OCNバーチャルコネクト特有の MTU 値（1460）周りの不整合が怪しいのか？これは今後の調査課題です。
【宿題4】全体の体感速度
スピードテストの結果は、文句なしの爆速化を遂げました！
- Fast.com: 約 200 Mbps
- Speedtest.net: 127.96 Mbps
二桁に届くことすら稀だった PPPoE 時代から、ついに三桁の大台へ。とりわけ以前はよく発生していた動画視聴のストレスが完全に解消されました。
最後に判明した「最大のオチ」
動画視聴環境は改善された。しかし、ここで完全に見落としていた「致命的な仕様」が牙を剥きます。
NVR500時代、私の環境では、Raspberry Pi による VPN サーバーが稼働していました。RTX1210に切替えた当初は「動画は爆速 IPoE、VPN は従来の PPPoE」という二刀流を構成するつもりだったのですが……。
RTX1210 で何度設定を入れても、PPPoE の認証が通りません。不審に思い、hi-ho の公式サイトを読み返すと、そこには残酷な一文が。
「※IPv6_IPoE接続サービスをご利用いただく場合、PPPoE接続はご利用いただけなくなります。」
言葉を失いました。IPoE が開通した瞬間、私の PPPoE セッションは物理的に「封鎖」されていたのです。
これにより、ポート転送を前提としていた VPN 環境は崩壊。外出先から仕事場へ入るルートは完全に断たれました。
次なる戦いへ
速度（IPoE）を手に入れた代償に、自由（PPPoE）を失った。
しかし、ヤマハのビジネスルーターを導入した以上、ここで引き下がるわけにはいきません。PPPoE が使えないなら、解決策はただ一つ。
OCNバーチャルコネクトの厳しいポート制限を回避できる、「IPv6 アドレスをターゲットにした IKEv2 VPN」の構築です。
次回、この「閉ざされた IPv4 の壁」を突破し、IPv6 の世界から仕事場へのリモートアクセスを再建するまでの格闘を報告したいと思います。
私のネットワーク再構築の旅は、まだまだ終わらないようです。
本日も最後までお読みいただきありがとうございました。
それでは、よいインターネットライフを！
ピンバック: 28年使い続けた hi-ho と PPPoE の限界に気づいた日 – IPv6 IPoE への移行を決意するまでの記録 - ビューローみかみ