最近インターネットの調子が悪い。しょっちゅう通信が詰まる。通信が詰まっても数十秒で復帰するのですが、日に何度も発生しておりかなり困っています。
10GルーターUbiqiti Dream Machine Proを購入した
自宅ではUbiquiti Dream Machine Pro（UDM）をルーターとして利用しています。UDMではWANを2系統用意できるため、片方の回線で障害が発生したときに別の回線を利用できます。通信が詰まる時間は数十秒ですが、この機能により主回線 → 副回線にフォールバックしてその後に主回線に復帰するまで1分程度通信が詰まります。
この通信が詰まっている状態、復帰直後にSpeedTestを実行しても通信速度が落ちている等はありません。この症状、おぼろげながら原因が浮かんできます。これ、NATテーブル溢れだ……
NATとは
インターネットに接続する際にルーターに接続されたたくさんの機器が1つのグローバルIPを共有して外に出ていきます。この時使われるのがNATです。
ルーターは通信ごとにどの機器からの通信かを記録して、外から戻ってきた通信を元の機器へ届けます。 普段は意識する必要はありませんが、同時にたくさんの通信が流れるほど、この記録テーブルが増えていきます。
NATテーブル溢れとは
ルーターのNATテーブルが満杯になり、新しい通信ができなくなる状態です。 Webやアプリが急に固まったようになり、数十秒すると自然に復活する…… といった問題が発生します。
ルーターの配下にたくさんの機器がぶら下がっていたり、一台の機器でも数多くの通信を行っていたりすると発生します。
現在の自宅の環境では、50〜60台程度の機器が繋がっておりまさにこの状態です。また、ルーターはマンション内の全世帯で共用されており、各家庭にマンションルーターからプライベートIPが割り当てられています。そのため1つのグローバルIPを複数世帯で共有する構造のため、1世帯で使えるNATのテーブル数はさらに少なくなっています。
現状確認
現状、我が家の通信量はどの程度あるのか確認します。幸い、UDMにはたくさんのログ取得機能があるのでInsightのページで簡単に確認できます。
1か月の通信回数は856万回でした。1時間に1万2千回程度の通信となります。1つのグローバルIPを占有できるのであればこの程度は捌けますが、今回の複数世帯共有という状況では厳しいかも知れません。
各機器毎の通信情報も確認可能なため確認すると概ね下記が多数の通信を発生させていました。
- DNS
- Tailscale
- UDMのPing
- LLMエージェント
- Google Home
DNSとTailscaleの通信量については対策が可能なので対応を行います。
UDMのPingについては、WANの接続状況を監視するためにUDM側で自動で行われている物で対策が難しいです。
LLMエージェントについては、LLMとの接続で多数のセッションやセッション時間が長いという課題がありますがこちらも解決策は思いつかないため対策が難しいです。
Google Homeに関しては宅内に4台あり、それぞれが数秒毎にGoogleと接続していました。これも対策のしようがないです……。
DNS対策
DNSについてはこれまで、「1.1.1.1」を各機器にDHCPで広報して利用していました。これではgoogle.comというドメインをIPアドレスとしてDNSで引くときにすべての機器が同じ結果になるものを毎回問い合わせるというムダな通信が発生していました。
今回は宅内にDNSサーバーを新設しました。「AdGuard Home」サーバーを立てました。
GitHub - AdguardTeam/AdGuardHome: Network-wide ads & trackers blocking DNS server
AdGuard HomeはGitHub Repositoryのシェルスクリプトを動かすだけでお手軽にDNSサーバーを立てることができます。
アップストリーム設定
設定は下記の様にしました。上流のDNSサーバーの設定は下記にしました。
1.1.1.1
1.0.0.1
8.8.8.8
8.8.4.4
https://cloudflare-dns.com/dns-query
https://dns10.quad9.net:443/dns-query
ロードバランシング設定で運用しています。
DNSサーバー設定
頻度制限は「0」にして無制限にしました。各機器のDNS設定はルーターのIPアドレスにして、ルーターがAdGuard Homeに問い合わせるという形にするため無制限としました。
キャッシュ設定
WAN側への問い合わせを減らすため、DNSキャッシュを有効化します。キャッシュサイズは64MB、最小と最大TTLも上書きをして最低30秒はキャッシュするようにしました。
効果
24時間のDNSクエリは約13万回程度ありました。
DNSサーバーからWAN側へのアクセス数は24時間で約4万回でした。
これでこれまで24時間で13万回あった通信が3分の1程度に減り劇的な通信数削減となりました。
Tailscale対策
続いてTailscaleの通信を対応します。Tailscaleをインストールしている端末からは世界中への通信が発生しています。
これはTailscaleのDERPサーバーとの通信です。
DERP servers · Tailscale Docs
Tailscaleはポート開放ができないような環境でもVPNで通信が可能です。この通信の確立のために世界中に設置されたDERPサーバーで接続を確立します。
またTailscaleの端末同士が直接接続できない場合はDERPサーバーで通信そのものが中継されます。この仕組みにより、ユーザーはTailscaleをインストールするだけでVPNネットワークを構築できます。
問題はルーター配下に複数台Tailscaleを入れていると各クライアントからDERPサーバー宛の通信が大量発生します。
この問題の対策としてDERPサーバーを個人で立てて経路をある程度固定するという逃げ方があります。
Custom DERP Servers · Tailscale Docs
ですが、今回はより制御が行いやすい別のVPNへの移行を行いました。
さくらインターネットのVPS上にWireGuardをインストールして、UDMのVPNクライアント機能で接続を行いました。これによりVPS上にVPNで接続して自宅ネットワークにアクセスできるようになりました。こちらは別記事で解説する予定です。
Tailscaleは大変便利なシステムなのでApple TVのTailscaleのみ残して非常時のアクセス手段としては引き続き利用することとしました。
Apple TVでお手軽にVPNサーバーを構築
対策結果
DNSサーバーの新設、Tailscale利用の削減（5台 → 1台）により1時間の通信数が1万2千 → 8千回に削減できました。
この対策でNTT回線が詰まることはなくなりました。恐らくマンションの他の世帯にも影響を出していたと思うので早めの対策ができて良かったです。
ただ今後も通信数は増えていくでしょうし、IPv6に関しては多重NATで上流のマンションルーターが良い感じにIPv6アドレスを配布できないため利用できません。
どうにもこうにもならなくなったら、通信をすべてVPS側に流すことでVPS側のグローバルIPが利用できるためいずれ検討が必要になるかもしれません。
