VPNがルーターで動くとき、STUN応答が明らかにするもの
ルーターのトンネルアドレスはブラウザのローカルアドレスではありません。リフレクターが何を報告するかを読む前に、各リクエストがどう経路選択され、変換されるかを追跡してください。
トンネルがルーター上にあるとき、ブラウザを動かしているマシンにはトンネルインターフェースが一切ありません。そのマシンにローカルアドレスを尋ねると、プライベートなLANアドレスとループバックが返ってきて、VPNアドレスに似たものは何もありません。それでも遠端のSTUNサーバーは経路について意味のある何かを報告でき、その内容は、その特定のリクエストがどのように経路選択され変換されたかに完全に依存します。
ここは立ち止まって考える価値のある部分です。「ブラウザがVPNアドレスを所有しているわけではない」というのはインターフェースについての問いへの答えであり、反射されたアドレスは変換を経た経路についての答えです。両者を混同すると、証拠が支えない開示に関する断定的な結論が生まれます。
二台のデバイス、二組のインターフェース
ルーターベースの構成では、トンネルはルーターで終端し、LANクライアントは通常のトラフィックをデフォルトゲートウェイへ送ります。クライアントのインターフェース一覧は短いままで、プライベートアドレスが一つ、別ネットワーク用にもう一つ、そしてループバックだけです。リスクは、そのどれかがたまたまトンネルアドレスであることではなく、リクエストが自分が選んでいない経路から出ていくことです。
どのインターフェースが存在するかを尋ねる代わりに、クライアントに特定の宛先がどの経路を取るかを尋ねてください。答えはゲートウェイとカーネルが使う送信元アドレスを名指しし、それはどのアドレス一覧よりもすでに情報量が多くなっています。
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsドキュメント用のアドレス範囲は、実際のサービスに解決されることが決してないため、テスト先として適しています。クライアントが言うこととルーターが言うことを比べ、少しでも食い違えば、ポリシールーティング、スプリットトンネルの規則、あるいは二番目のデフォルトルートが、自分が想定していないことをしている証拠として扱ってください。
Binding応答が言ってよいこと
RFC 8489はBindingリクエストと応答を定義しており、サーバーはそのリクエストについて観測した送信元トランスポートアドレスを報告します。これはある瞬間の一つの五タプルについての表明であり、クライアントのインターフェースの調査ではありません。したがって興味深いことはすべて、クライアントと観測点の間で起こります。
その隙間を埋めるのがルーティングと変換です。外向きトラフィックに送信元NATをかけるルーターは、クライアントのプライベートな送信元を、出口インターフェース上の自身のアドレスに置き換えます。そのインターフェースがトンネルなら、リフレクターはトンネルアドレスを見ます。パケットがトンネルから除外されていれば、リフレクターはWAN変換が生み出したものを見ます。同じクライアント、同じリフレクター、異なる答えです。
似ているようで似ていない三つのケース
有用な区別はパブリック対プライベートではなく、どの執行点がパケットを扱ったかです。一つのブラウザが書き忘れた規則次第で三つすべてを生み出し得るため、ルーター自身のテーブルを開いたままケースを追ってください。
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
二番目のケースだけが、一部のトラフィックが決して直接出てはいけないという要件を破り、一番目と三番目のケースだけがトンネル側の識別子を開示します。三行のどれも特定のプロバイダーの挙動についての主張ではなく、プライベートなリフレクターに到達できるかどうかは、ルーティング、相手側の許可されたIPアドレス、両端のファイアウォールポリシーに依存します。
同じプロバイダーのアカウントを持っていても、そのどれも証明されません。ルーティングされたリクエストは、何も変換しなければクライアントのLAN送信元を保つことがあるので、送信元フィールドはトポロジー図から推測するのではなく追跡する必要があることも覚えておく価値があります。
収集は選択ではない
WebRTCは試すべき候補アドレスを収集しますが、診断リストに現れる候補が実際にメディアを運ぶとは限りません。そのリストを「これが相手が学んだことだ」と読むのは証拠を過大評価しています。実際にセッションを運んだのは選択されたペアであり、それは別のフィールドにあります。
HTTPSの出口チェッカーは、そのリクエストについてWebサーバーが見た送信元アドレスという、さらに別の問いに答えます。これが有用な照合になるのは、UDPリフレクターとは異なるプロトコルと、しばしば異なる宛先を使うからであり、両者の食い違いは通常、バグではなくルーティング規則を指します。
ポリシーを決めてから答えを読む
テストの前に、どのトラフィックがトンネルを使わなければならないか、どれが直接出てよいか、どのアドレスファミリーが対象か、トンネルが落ちたときに何が起きるべきかという意図を書き出してください。その基準線がなければ、故意に許可した経路と漏洩を切り分けられないため、すべての観測は曖昧になります。
次に一度に一つずつ問いかけてください。この宛先はどの経路を取るのか。このリフレクターはどのアドレスを報告するのか。セッションはどの候補ペアを選んだのか。答えはポリシーの隣に置き、ファームウェア更新が昨年の結論を静かに無効にし得ることを踏まえて日付を添えてください。
ルーターは依然として強力な執行点です。クライアント自身を再設定しない限り回避できないトラフィックを見るからであり、あらゆるアプリケーションプロトコルのあらゆるフィールドが何も明かさないという約束でも、許可することを選んだ経路を書き留めることの代わりでもありません。