v6プラス(MAP-E方式) のポートが枯渇してインターネットに接続できなくなっていた

Date: 2023/10/27

Tags: Dns Map-E V6plus Troubleshooting

何もしていないのにインターネットに接続できなくなったと思ったら、思わぬ原因で発生していたという話。
非常に苦戦したので、その時の記録を残す。

結局何が原因だったのか

結論から話すと、以下が原因でインターネットに接続できなくなっていた。

マウスの設定アプリ(Logi Options+)の機能である Flow が自宅に存在しない実家のサブネットに対して UDP パケットを送り続け、NAT のセッションが大量に作成された。
大量に NAT セッションが作成されたことで、v6プラスでユーザに割り当てられる 240 のポートをすべて使い切ってしまい、新規コネクションが張れない状態になってしまった。
使用しているルータ(YAMAHA RTX830)では、より多くのセッションを処理できるように、ポートセービング IP マスカレードという機能があるが、UDP では使用されないため発生してしまった。
- ポートセービングIPマスカレード

以降の文章で、事象の発生から解決までの記録を記載する。

急にインターネットが繋がらなくなった

ある日突然、自宅で運用している k8s クラスタで使っているアプリから、以下のエラー通知が来ていた。 github.com の名前解決をしようとしているが、タイムアウトが起きているというエラー内容である。

FluxからのDNSエラー通知

また、名前解決だけでなくインターネットへの接続もできなくなる状態になっていた。調査をしようにもタイムアウトが発生したり、インターネットに接続できないなどのエラーが発生してしまう。

原因調査

発生した問題を解決するために、調査した。幸い、LAN 内の端末へのアクセスは問題なかったので、様々な端末へアクセスして挙動を確認しつつ、調べ物はスマホで実施した。

名前解決に失敗する範囲

dig か nslookup を使って、google.com で名前解決してみる。

端末	結果
Windows デスクトップ	失敗する
ルータ(RTX830)	失敗する

名前解決に失敗後、少し放置すると治ることがあるが、再発する。通信の大元であるルータで発生していることから、ルータに問題が発生していそう。

ルータからのインターネット接続の確認

ping を使ってインターネットの疎通確認を行う。接続先は DNSサーバに指定していた Cloudflare のパブリックDNSサーバ (1.1.1.1, 2606:4700:4700::1111) に対して確認する。

ping の対象	結果
IPv4 アドレス(`1.1.1.1`)	50~100% 程度パケロスして失敗する
IPv6 アドレス(`2606:4700:4700::1111`)	パケロスは発生せず、100%成功する

現在、自宅では IPv4 のインターネット接続に v6プラス(MAP-E方式) を利用している。 IPv6 のネットワーク上で IPv4 インターネットへの接続するための(IPv4 over IPv6) 技術である。

v6プラス(IPv6/IPv4インターネットサービス) | 株式会社JPIX

IPv6 は問題なく、IPv4 のみ問題があるのであれば、v6プラス周りに問題があるのではないかと考えた。

ルータの再起動

長い間再起動をしていなかったので、ルータを再起動することで事象が解消するか試みた。
再起動直後は解消しているが、時間が経過すると再発するため、なにか根本的な問題がありそう。

インターネット接続するためのケーブルの交換

VDSL 回線を使っているので、ケーブルの劣化によって通信ができなくなってしまう可能性もあったので交換した。 LAN ケーブル、モジュラーケーブル（電話線）どちらも交換したが、改善しなかった。

（よく考えてみると、ケーブルに問題があったら、IPv6 自体も接続できなくなるはずなので関係なかった。）

ルータのログを確認

ルータのデバッグログ等を有効にした状態でログを確認したが、原因の特定になるログは出力されていなかった。

大量に機器を接続したことによって許容量を超えた？

多くの機器を接続したことによって、使用できる帯域幅を使い切ってしまったのかと思い、自宅で動かしているサーバを1台ずつ電源をおとして様子を見てみた。しかし、Windows デスクトップ、ルータ、VDSLモデムのみ接続した最小構成でも、インターネットに接続できない事象自体は発生していた。
逆に、Windows デスクトップだけ起動していないときは、事象は発生していなかったため、機器の数は関係なさそう。

Windows デスクトップが起動している場合のみ事象が発生しているので、Windows デスクトップから発生している何らかの通信が影響を与えているのかもしれない。

セッション数の上限

実際、どれぐらいの接続が可能なのか。

ルータ(RTX830)

RTX830 の仕様を見ると、NAT セッション数の上限は 65,534 らしい。

ルータ内でコマンドを実行してセッション数を確認したが、セッション数は 1000 も超えていなかった。
(調査時の結果を取り忘れてしまったが、Peak でも 386 なのでかなり余裕がある)

> show nat descriptor masquerade session 1000 summary
NAT/IP masquerade compatibility type : 2
Interface            Desc Num    Outer Address                Current/Max  Peak
-------------------  ----------  ---------------------------  ----------- -----
TUNNEL[1](1)               1000  map-e/xxx.xxx.xxx.xxx           51/65534   386
-------------------  ----------  ---------------------------  ----------- -----

v6プラス

v6プラスは、IPv4 アドレスを複数ユーザで共有するようになっている関係上、割り当てられているポート数が 240 に制限されている。上限に引っかかるとしたら、こちらが先になりそう。

現在使用している YAMAHA ルータ(RTX830)では、ポート数に対してより多くのコネクションを張るための仕組みとして、ポートセービングIPマスカレードというものがあるらしい。しかし、TCP の場合のみ適用されるものであり、UDP の場合はそうでないらしい。

端末ごとのセッション数をコマンドで確認してみたところ、Windows デスクトップ(192.168.100.100)と VPN サーバ(192.168.100.A)のセッション数が非常に多い。
(Peak時に170となっている。VPNサーバが多いのは、調査時に VPN 経由で ping やら名前解決を大量に行ってしまったため)

> show nat descriptor masquerade session statistics
NAT/IP masquerade compatibility type : 2
...
Reference Descriptor : 1000, Assigned Interface : TUNNEL[1](1)
Inner Address   Session/Limit Peak  Over Limits Last Occurred
--------------- ------------- ----- ----------- -------------------
192.168.100.A         3/65534   170           0
192.168.100.100      15/65534   170           0
192.168.10.B          1/65534    43           0
192.168.100.C        13/65534    30           0
192.168.100.D         7/65534    30           0
...
--------------- ------------- ----- ----------- -------------------

Windows デスクトップの通信内容を見てみる

Windows デスクトップから不審な通信が発生していないかパケットキャプチャして確認してみる。

Wireshark で確認してみた結果、自宅とは別のサブネットに対して以下のような UDP パケットを定期的に送っていることがわかった。
UDPパケットではポートセービングIPマスカレードは適用されないため、v6プラスで割り当てられているポートを使い切ってしまったと思われる。

送信先である 192.168.1.211 は、自分のノート PC で実家の NW に接続したとき割り当てられた IP アドレス
- なぜノート PC に対してなのか、実家の NW で割り当てられた IP アドレスなのかは不明
送信先のポートは 59870 or 59781
3秒ごとに2~4回パケットを送信している

パケットキャプチャの結果

UDP パケットを送っているプロセスの特定

問題となっている UDP パケットを送信しているプロセスを特定しようとするが、UDP パケットの送信元ポートは定期的に変わってしまうため、netstat によるプロセスの特定が難しい。

ダメ元で、udp port 59780 で検索した結果、自分が使っている Logicool のマウスに関連するページが出てきた。 Options+ の Flow 機能：ポート情報 – Logicool B2B Support

Flowで使っているポート番号

定期的に発生している UDP の通信とポート番号が一致している。パケットの送信先がノートPCになっているのも Flow でノートPCとマウスを共有していたため、辻褄が合う。 Flow を無効化してみると、UDPパケットが一切送られなくなり、インターネットが接続できない事象も解消された。

以降、現在に至るまで一度も発生していない。

おわりに

まさか Logicool Flow が原因でインターネットに繋がらなくなるとは思わなかった。
調べてみても同様の事象が発生している人は見当たらなかったので、おそらくレアケースだと思う。
調査が難航し、原因にたどり着くまでに1週間かかってしまった。

今回のトラブルをきっかけに、YAMAHA ルータや v6プラスの NAT に関する知識を知るいいきっかけになったので良かったのかもしれない。

参考

QUICとNATで確かめたいと思うこと (MAP-EでのNATとNAT64) #nat - Qiita
NATディスクリプター機能概要
徹底解説v6プラス
- 8.2.7 ポートが枯渇した の節
Options+ の Flow 機能：ポート情報 – Logicool B2B Support