OpenWrtでOCNバーチャルコネクト(MAP-E)に接続する

2年越しの正直

OCNの輻輳がヤバいわよ!

NTT東西のフレッツがやっと10Gbps対応のフレッツ光クロスが発表された昨今ですが……最近またOCNの深夜時間帯(24時前後)の輻輳が酷くIPv4 PPPoEが5Mbps程度しか出ないことが頻繁に発生している。

ところでうちは現時点では光クロスはおろかいくつか開始された10G商用個人向けサービスでもエリア的にはeoくらいしか対応していない模様……

深夜の輻輳の後、明け方に突然600Mbps程度出るようになることが最近も過去にも何度かあったため実は対処可能な詰りかたをしているのじゃないかなどと勘ぐったりすることもあるものの、まあPPPoEだからってことで纏められてしまっているのでそういうことにしてくとして。

で、NTTとしてはPPPoEは限界だからDS-LiteやMAP-EなどのIPv4 over IPv6を使えってスタンスっぽい。光クロスも提供開始時点ではv6 IPoE+ v4 over v6のみの展開とリリースされている。(ただしプレスリリースに「PPPoE方式については、準備が整い次第提供予定となります。」とあるのでPPPoEも提供するみたい。)

OCNはOCN v6アルファOCNバーチャルコネクトと称して IPoEのVNCと、その上で利用可能なMAP-Eによるv4 over v6トンネルの提供をOCNやその他のOCNバーチャルコネクトを利用しているISPユーザーに提供している。v6アルファ/v6アルファ自体はOCN for ドコモ光を除いてレンタルルーターを含め月500円で提供されているが、MAP-E自体はこの契約がなくも利用できることが判明している。そもそもOCN以外なら最初からいらないってわかってたんだからOCNだけオプション必要なのもおかしいでしょ。

最近はNTTComやドコモなどから発売、レンタルされているルーター以外にも各社から販売されている無線LANルーターなどでもOCNバーチャルコネクトのMAP-Eを経由する接続が行えるようになったので導入の敷居はかなり下がっているものの、残念ながらうちに公式に対応しているルーターはない。(1世代あとなら対応してたんだけどな……)

OpenWrtでMAP-Eしてみる

OCNの割当アドレスのアドレスマッピングについては提供開始早々にかなりの調査がおこなわれていたのは懐しいが、ここ1年で色々と情報も増えたようでOpenWrtで接続できそうだったので試してみた。うまくいかなかったり行き詰まったりして一晩かかったけど疎通確認はできた。

うちのネット環境は2年前から特に大きな変化はない(端末はけっこうかわったけど)のでそちらを参照。

v6プラスのエントリであるが、以下のエントリが結構参考になった。


あくまでも疎通確認を目的とした実験として、仮想マシン上のルーターにおいて接続を行い、他のマシンからの接続のルーティングは行っていない。が、まあ通常通り設定すればいいだろう。

実験環境

Arch Linux (Linux 5.5.8-arch1-1 #1 SMP PREEMPT Fri, 06 Mar 2020 00:57:33 +0000 x86_64 GNU/Linux)のラップトップ上のVirtualboxにて最新のOpenWrt x86_64 (OpenWrt 19.07.2 r10947-65030d81f3, kernel: 4.14.171)を展開した。

関与するネットワーク機器としてはHGW(RT-500KI), Aterm WG2600HP2であり、ラップトップはこのAtermに866.7 MBit/sリンクの無線LANで接続されている。(ping2.5ms)

下準備

手元にちょうどいいOpenWrtルーターはなかった(つかえそうなやつは先日こわれてしまった)ので、前述のとおりVboxにVMを建てた。別にVBoxである必要なくて何でもいいんだけどとりあえず勝手がわかってるもので。

VirtualBoxにおけるOpenWrtの初期設定はおおよそWikiにある通りだが、今回はIPv6ネットワークが必須なので最初から多少ガイドに逆らっている。

まず、VMには以下の3つのネットワークアダプタを接続した。

  • eth0: hostonly adapter
  • eth1: NAT adapter
  • eth2: bridge adapter (to Wi-Fi)

v6を回すためブリッジアダプターは欠かせなかったが、NATアダプターは今回はなくてよかったかもしれない。

最初のうちはv4(PPPoE)をeth1、v6をeth2から回していたが……別に今おもえばeth2でよかったこれ。どうせLAN側にはならないんだし。

とりあえず用意したVMにSSHして諸々の初期設定をし、インターネットに接続を確認できたらopkgで mapcurl のパッケージは追加しておく。

また、マッピングルールも計算しておく。大概のアドレスは例のツールで網羅されているはず。OCNの2400:4000::/22以下のアドレスはip6prefixlen 38,ip4prefixlen 20らしい。ツールにOCNアドレスを入力すると「未対応のプレフィックス(一部地域のみ対応)」とアラートが表示されるが、これだけが出るなら多分問題なく計算できている。

IPv6インタフェースの設定

自分は初期設定においてDHCPv6のインタフェースwan6をただeth2に向けるだけの設定をしていたが、この場合HGWが/60のサブネットを割り当てるためIPv6 PDがMAP-EのCEとprefixが一致せず疎通できない原因となることが後に判明した。このことはYAMAHAのv6プラス設定例でも明記されている。

もとのは停止し、複製したインターフェスwan6sを用意したので以後それで表記するが、このwan6sのCustom delegated IPv6-prefix (ip6prefix) にHGWがRAで広告しているものと同じ64のprefixを指定することで(健全なルーターにはみえなくなったが)ひとまずこの問題が回避でき、インターネットに疎通がとれる。

ひとまずこの段階でpingやcurlによるhttpリクエストがv6で通るか確認しておくとよいだろう。

Shell

MAP-Eの設定

やっとこさ本題。

先に計算したマッピングデータをもとに、インタフェースの設定をする……のだが、ここで2つの問題が発生した。

BRのアドレスがわからない!

luciのインタフェース設定から「MAP / LW4over6」を選択し、項目を埋めていけばよいのだが、肝心なことを忘れていた。BR、すなわちトンネル対向のIPアドレスを把握していなかった。

JPNEのv6プラスにおいてこのアドレスが 2404:9200:225:100::64であることは有名であるが、OCNのBRアドレスは公開されていない。どうやら回線ごとに異るとの説もある。

どうやら公式の方法としてはここに掲載されているようなAPIから取得できるみたいなのだが、残念ながらAPIキーはわからない。

何か手段はないかと探っていたところ、どうやらHGWのパケットフィルタのログからこのIPアドレスを発見できるという。そういやOCN管轄の謎のIPアドレスからのパケットがパケットフィルタのログに以前でていたのを思い出し確認してみたところ、まさにそれらしきアドレスからCEのIPアドレスへのログがみつかった。

どうやら、これがBRのアドレスのよう。アドレスの後にある4IPIPトンネルのプロトコル番号である。

もしパケットフィルタのログに出ていない場合、出口v4アドレスの割当ポートのうちのいずれかに適当なパケット(HTTPでよい)を投げるとパケットフィルタのログに出てくる。(ところでこのIPアドレスをぐぐるとヒステリックになってる人がでてくるくらいなので伏せる必要もなさそう)

設定が保存できない!

無事BRアドレスがわかったので各フィールドを入力し保存しようとしたところ、保存ボタンをおしてもスピナーがぐるぐる回るだけで先にすすめない。保存できてるのかとおもい モーダルを閉じるも、変更は反映されていない。コンソールをみてみると、2種類のJSエラーが発生していることが確認できた。バグ?

仕方ないのでSSHから直接設定を弄ることにする。ほんとはuciからやるべきだろうけどめんどいので直接config編集。

あ、そうそう、/lib/netifd/proto/map.shを編集してlegacy modeを有効化するのも忘れずに。

で、 /etc/config/network の当該インタフェースの設定は以下のようになった。例の計算スクリプトはOpenWrtで使える形式で出力してくれているので親切。(まあそのためのものだから……)

firewallのzoneは/etc/config/firewallで追加すればいい。こっちはucsでやった。

この状態でwan6s, wan_mapeを順に起動すると wan_mape_ としてCEのアドレスをもった仮想インタフェースが起動する。

MAP-E接続を行った状態のインタフェース設定

疎通テスト

接続の確認

まずはpingを飛ばしてみる。接続直後は返事の帰ってこないことがあったが、30秒ほどおいてみると問題なくつながる。

当然ながらこれだけでは経由しているネットワークが確認できないのでIPアドレスを確認してみる。

ところで、ipaddr.gaにはJSONでIPアドレス以外の情報も簡易的に返す機能を用意していた。これを使うと、逆引きホストやリクエストポートの確認ができる。

portがMAP-Eによる割当範囲内であることも確認できる。

また、tracerouteも叩いてみた。最初に表示されるルーターはPPPoEではふだん4番目あたりにやっと表れる 153.149.204.* のもの。BRが県域ネットワーク外にあるためなのかな、などと。

自宅PPPoEのIPとBRの出口アドレスを相互にtracerouteしたところ同様のルートで少なからず遠回りしているような経路がみえる。仕方ないが。(IPoEのPOIはH30/3の資料で東京と大阪にしかないしまあそういうこと。まあPOIは以降の2年間でいくつも開設されているが。)

スピードテスト

speedtest.netのCLIツールが様々なCPUアーキテクチャ向けにバイナリで提供されているのでこれをDLして利用する。今回はx86_64VMなのでそれ用のものを使用している。

比較的安定し、意識せずともv4アドレスで接続できるサーバーとしてOPEN Project (via 20G SINET) (15047)を相手取り、帯域幅測定を何度かおこなった。(楽天モバイルなどの提供するサーバーはIPv6に対応しているため、オプションを指定されないとそちらが優先されかねない)

ホストのArchでも同様にPPPoE経由で同サーバーを利用した測定をつづけて行ったが、PPPoEの空いている時間帯(下り600Mbps)や混雑している時間帯(下り10Mbps以下)などを問わずして安定して下り100~110Mbps、上り90-100Mbpsあたりを得られた。

VMで行っているもあるだろうが、よくも悪くも回線の混雑度の影響を受けていない。様子をみている限り、必ずしもPPPoEより速いわかではなく、むしろ異常に混雑している時以外はPPPoEの方が速いことの方が多い。上りについては混雑時でもPPPoEの方が速い。うちでは。

何故か接続がきれる

接続直後は問題ないのだが、数時間放置しているとIPv6のパケットが入ってこなくなる。VMでブリッジしているためかもしれないし、RA proxyをするわけでもなく雑にDHCPv6を使用しているためかも原因はよくわかっていないが、外部のv6アドレスに(あるいはLAN内についても)pingを送っても帰ってこなくなったりする。パケットキャプチャをみてもどうも外向きに問題があるようには見えない。当然ながらコネクションプールには余裕しかないので謎。RA Relayあたりの設定……とか経路設定が正しくないとかありそうだけどよくわからん、すこし違うきがする。経路みても問題なさそうだし……まあWLANのVMだし仕方ないか(?)

まとめ

VM上にOpenWrtのルーターを建ててMAP-Eのトンネルが張れることを確認するやつをやった。

手を動かしてみるとトンネル自体は結構単純なIPIPトンネルであることが確認できたりしたものの、マップルールの計算とか複雑だったり通知方法が標準化されてるわけではなかったりするのは少し厄介ともわかった。

あと、IPoEは必ずしもPPPoEより速いとは限らないし、その上を通したトンネルが速いとも限らない。もちろんPOI拡張性などといった接続上のメリットもあるが。


追記のコーナー

ねぼけ眼でやったのとか途中あいちゃったとかで色々わすれてるところがあったので指摘大歓迎。

ポートセットが使いきれてなくない?

ほんまや……

上記gistのとおりSNATにマッチングルールを追加する。

v6プラスでは16*15の240のポートしか割当られないらしいが、OCNでは16*63の1008ポートが割り当てられるらしい。実に4倍以上。240のままじゃあれなのでとりあえず倍の480まで使うようにしておいた。SNATテーブルの様子はiptables -t nat -L -vで確認できるが、もし公開用に4桁ポートを使うつもりでもあれば頭10組くらいは飛しておいてもいいかもしれない。とりあえずそんなことは考えずに480ポートをFIFOで割り当てるようにしてみた。

雑に再起動してポートの分散していることを確認できた。

ところで、書いてから気づいたけどfirewall.userはシェルスクリプトなので雑にループ書いた方がフレキシビリティだとかも含めいいきがした。ので変えてみた。大方NanoPi NEO2をv6プラスのルーターにする 後編 – がとらぼのスクリプトを流用させてもらった。

FIFOだから使い方によっては効率よくないみたいな話もあるけどまあ480あれば早々問題にはならんやろ……


VMのeth4をX395の有線LANにブリッジさせてX240を有線のみで繋ぎ、いいかんじにルーティングするやつを試行しているが、IPv6のルーティングがうまくいってないっぽい……v4はうまくLANとトンネルに振り分けられてるんだが……

広告

コメントを残す