以前に「RouterOSで「enひかりクロス with Xpass」を使う」で書いた通り、自宅のインターネット回線に「enひかりクロス with Xpass」を利用してから間もなく1年が経過する。
近頃、ブラウジングしていると接続が詰まるような現象がしばしば発生していた。再現性がよくわからない状態が続いていたのだが、あるタイミングでTCP/UDP接続が途端にタイムアウトする状況が発生することは分かっていた。最初はルータに用いているRouterOSの設定不備等を疑っていたのだが、色々切り分けているとどうも宅内に原因があるようには思えなかった。
ネット検索していると以下の記事を見つけ、Xpass (DS-Lite) のAFTRのNAPTのポート枯渇を疑い始めた。
円安の影響でVPSやクラウドサーバが高くなったためそれらで動かしていたサービスを自宅サーバへ移設したりなど、常時張られるセッション数が増加するような心当たりはあった。
この疑いをより確実なものとするため、XpassのAFTRのNAPTの挙動を調査して、公開されていない割り当てポートの仕様を推測した。
検証方法
環境:
- 回線: enひかりクロス
- ルーター: MikroTik CCR2004-16G-2S+
- OS: RouterOS 7.24.4
手順:
クライアントPCから、2台のVPSを使って以下のIPv4通信を実行する。
- 毎秒10本ずつTCP接続を試行、確立した接続は一定時間保持
- クライアント側では各接続の成功可否、VPS側では送信元IPアドレスとポートを記録
検証結果
| 検証内容 | 同時に確立できたTCP接続数 |
|---|---|
| 1台のVPS宛て | 471 |
| 2台のVPSへ交互に接続 | 486 |
- 上限付近では新規接続がタイムアウトした
- 宛先を2台に分散しても同じくらいの数で接続数は頭打ち
なお、検証用クライアント以外の通信も存在している環境のため、RouterOSのIPv4 Firewallのconnection trackingを同時に観察していたところ、検証用以外のTCP接続を含むと512〜516件前後の追跡エントリが確認できた。
マッピングされたポート番号
VPS側に記録された送信元ポートを確認すると
- 1280-1407
- 4480-4607
- 7680-7807
- 11648-11775
のように、128の倍数を開始値とする1ブロック128ポートの範囲が用いられていた。
このポート範囲と、同時に保持できたTCP接続数が500前後で頭打ちになった結果から推察するに、128ポートのブロックを4つ、合計512ポート割当てるという仕様なのでは。
UDPを加えた追加検証
上記の検証に加えて、UDPも試してみた。(ソケットごとに異なる送信元ポートを使い、20秒ごとにkeepalive用データを投げるような作り)
例えば、TCP接続を400件保持したままUDPセッションを追加すると、UDPは90件程度で頭打ちになった。TCPとUDPが合計512ポートの割り当てを共用していると思って良さそうだ。
さらに、同じ内部IPアドレス・送信元ポートから2台のVPSへ通信する実験をしてみると、双方のVPSで同じ外部IPアドレス・ポートであることを確認した。これはいわゆる Endpoint-Independent Mapping(EIM)の挙動である1。
まとめ
- Xpass (DS-Lite) の割当てポート数は512っぽい2
弊宅の環境からするとやや心許ない上限であることが分かった。
ということで、結果的に enひかり固定IP1オプション を申し込んだ。電話した翌日に開通したよ。サイコー
EIMについて、UDPは RFC 4787 §4.1、TCPは RFC 5382 §4.1を参照。 ↩︎
この仕様がenひかり契約ユーザ固有のものなのか、楽天ひかりなどの他社でも同様なのかは不明。 ↩︎