対称型 NAT と VPN：ラベルではなくマッピングを測る

サポートスレッドは「対称型 NAT だから、この VPN はここでは動かない」という断定で終わり、その後クライアントが理由もなく三回再インストールされる。このラベルは誰も尋ねていない問いに答えるため、害になる。固定サーバーへ外向きに接続するクライアントは、最初のパケットを送った瞬間にマッピングを作り、応答はほとんどすべてのネットワークが実装している規則の下で戻ってくる。エンドポイント依存のマッピングが本当に複雑にするのは、二人のピアが同時に互いへ到達しようとする場合であり、それは別の試験である。

一つのラベルの裏に二つの問いがある

第一の問いは、このネットワークの背後にいるホストが既知の公開アドレスとポートへセッションを開けるかどうかである。トンネルのクライアントにとってそれは通常のケースであり、答えはほぼ常に「はい」である。ルーターは内部の送信元を記録し、外部ポートを割り当て、応答が内側から始まったセッションに属するため通過させる。

第二の問いは、異なるネットワークの背後にいる二つのホストが、間にサーバーを置かずに共通の経路を見つけて互いに送信できるかどうかである。それは各ネットワークが外部ポートをどう割り当てるかに依存し、マッピングの挙動が意味を持つのはそこだけである。

二つを混同すると、典型的な誤診が生まれる——ピア・ツー・ピア機能が失敗し、誰かが NAT タイプの試験を実行し、最悪の分類を見て、通常のトンネルも動かないと結論する。失敗したのはトンネルではなかった。

マッピングとフィルタリングは別々の性質である

RFC の用語はベンダーが使う名前より正確であり、議論を決着させるのでチケットに持ち込む価値がある。マッピングとは外部ポートをどう割り当てるかである。フィルタリングとは、どの受信パケットを通過させるかである。一方で厳格、他方で寛容なネットワークはあり得て、その組み合わせこそピア・ツー・ピアのプロトコルが耐えなければならないものである。

三行目は、ほとんどの家庭用ルーターと携帯事業者が「対称型」で意味しているものである。このラベルは割り当てだけを記述している点に注意してほしい。そのマッピングと寛容なフィルタリングを持つネットワークでも、たった今割り当てたポートへの受信パケットは受け入れられることがあり、だからこそホールパンチングは成功する場合と失敗する場合がある。

フィルタリングには独自の三つのケースがあり、それぞれに独自の名前がある。「アドレスとポート依存のフィルタリング」を意味するときにチケットへ「対称型 NAT」と書くと、次の担当者をマニュアルの間違った章へ送ることになる。両者は試験で異なる挙動を示すので、この誤りは観念的なものではない。

名前を付けるのではなく測定する

自分が管理する任意の UDP サービスのサーバー側から、割り当てられたポートを直接観察できる。公開ホストでキャプチャを開始し、クライアントから送信し、パケットが到着した送信元ポートを読む。

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

エンドポイントの行は三つのうち最も有用である——WireGuard は各ピアから最後に受け取ったアドレスとポートを記録するからだ。そのポートを、クライアントが使っていると考えているポートと比較する。何らかの変換が起きているときは必ず両者は異なり、重要な問いはその値が安定しているかどうかである。

二つ目の宛先ポートまたは二つ目のサーバーに対して同じ観察を繰り返し、もう一度比較する。外部ポートが宛先ごとに変わるなら、マッピングはアドレスとポートに依存している。同じままであれば、ネットワークは一つのマッピングを与えており、探索には望みがある。

STUN ベースのツールは同じ分類を一段階で報告し、ネットワークが公開 STUN サーバーへの外向き UDP を許可している場合には使ってよい。許可していない場合でも、上記のキャプチャ手法は機能し、すでに管理しているホスト以外は何も要らない。

失敗に合った対処を選ぶ

失敗している機能がピア・ツー・ピアなら、支持される答えはリレー、両方のピアが到達できるランデブーサービス、または別のトポロジーである。TURN はまさにそのために存在し、自前のリレーを同梱する製品は、一部のネットワークが敵対的であることを想定していると告げている。

失敗している機能が通常のトンネルなら、マッピングの挙動は問題ではなく、上記のいずれも当てはまらない。クライアントが実際に送信しているか、サーバーがパケットを見ているか、応答が戻ってくるかを確認する。その順序は三つの観察であり、ルーターの NAT 分類を知る必要はまったくない。

うまくいかないのは、何かが接続するまでローカルポートの変更をばらまくことである。クライアントの送信元ポートを変えても、ネットワークがマッピングをどう割り当てるかは変わらない。五回目の偶然の成功は偽陽性であり、何か月も「解決策」として引用される。

判定ではなく構成を記録する

役に立つメモは、どのプロトコルか、セッションがどちら向きに始まるか、経路上にリレーがあるか、回線上で何を観察したかを述べる。「対称型 NAT なので動かない」は使えない——トンネルについて誤りであり、同時にピア経路について何も語らないからだ。

試験したのであれば、測定したポートの安定性とフィルタリングの挙動を含める。その二つの事実があれば、他の誰かが調査全体を繰り返さずに、新しい機能がそのネットワークで動くかを予測できる。また、ヘルプページごとに少しずつ意味の違うベンダーの分類より、長持ちもする。

最後に、書き上げるときは RFC 4787 の用語を手元に置いてほしい。正確な用語を使うのに必要なのは一文だけで、次の読者が同じ誤診を繰り返すのを防げる——それこそがメモを書く目的そのものである。