ルーター上の VPN で STUN が見る送信元アドレスとは
経路、送信元の選択、変換の三つがリフレクターの報告するアドレスを決めます。書き留めるべき三つの事実と、どちらの経路が勝つかを確かめる一つの問い合わせ。
この問いは一度の検索に見えて、実際には三つの判断です。binding request がどの経路を通るか、その経路に対してカーネルがどの送信元を選ぶか、そして途中で何かがその送信元を書き換えるか。どれか一つを変えれば、STUN サーバーが報告するアドレスも一緒に変わります。だから「VPN はルーターにある」と言っても、それだけではほとんど何も分かりません。
判断は三つの事実に支えられている
第一に経路では、ポリシールールと経路テーブルが、要求がトンネルから出るのか通常の WAN から出るのかを決め、除外された宛先はトンネルが上がっていても二つ目の経路を選びます。第二に送信元では、カーネルは選ばれた経路に対して送信元を選び、その選択は経路の優先送信元と一致したルールに依存します。第三に変換では、途中の NAT が選ばれた送信元を置き換えます。反射されたアドレスは三つの積であり、トンネルの性質ではありません。
三つのうち一つを変えれば答えは変わりますが、どの構成要素も自分のログでは健全に見えたままです。これがこの診断が行き詰まる通常の理由です。
始める前に、試すフローについて三つの事実を書き留めてください。インターフェース、経路、変換ルールだけで結果を予測でき、その予測こそが驚きを有益なものにします。三つのうち一つでも埋められないなら、その空白が本当の発見です。
一つの binding request を経路に沿って追う
STUN の binding request は、観測した送信元トランスポートアドレスを報告するようサーバーに求めます。応答は要求がたどった経路を説明しますが、クライアントマシン上のインターフェースの一覧ではありません。二つの経路を通る二つの要求は、正直に二つの異なるアドレスを報告します。
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
その表は提供者のメニューではなく、条件の集合として読んでください。真ん中の行は、私的なリフレクターがトンネル自身のルーティングとピアポリシーの下で到達できることを要求しますが、これは検証できる設定上の事実であり、アカウント階層が含意するものではありません。下の行は、その通信がトンネル内に留まるはずだったため、通常ポリシー上重要です。その間に通常の場合はあり、出口が変換し、リフレクターは出口だけを見ます。
ホスト候補とサーバー反射候補は異なる仕組みから生まれるので、候補リストはメディアが実際に使った経路を語りません。セッションがどこへ行ったかを知りたいときは、収集ログではなく選択されたペアを読んでください。
ルーターのトンネルアドレスではないもの
ルーターに割り当てられたトンネルアドレスは、ルーター上の一つのインターフェースに属します。LAN ホスト上のブラウザーは自分自身のインターフェースアドレスを持ち、ルーターのトンネルインターフェースを直接見ることはできません。両者を交換可能として扱うと、ウェブページが何を学べるかについて自信に満ちた誤った答えが生まれます。
転送が両者を結びつけます。要求はルーティングされた通信としてルーターを通過し、その送信元はルーティングと変換が生み出したものです。
トンネルの経路が LAN の送信元を保つなら、私的なリフレクターはその LAN アドレスを学べますが、これは真正の開示であり、トンネルアドレスとは別物です。経路がトンネルアドレスに変換するなら、リフレクターは代わりにトンネルアドレスを学びます。どちらの結果も同じホスト上の同じブラウザーと整合するので、観測は特定のフローに結びつけなければなりません。アプリケーションを責める前に、カーネルがどの送信元を使うかを尋ねてください。
開示と迂回：二つの発見、二つの修正
反射されたトンネルアドレスは、許可した経路で内部識別子を開示します。WAN 経由の直接要求は、必須にしたかった経路を迂回します。前者は情報の問題、後者は強制の問題であり、修正する場所が異なります。両者を一語にまとめると、どちらも扱わない修正になります。
WebRTC は、候補を集めることがそれを選ぶことと同じではないため、これを誤りにすることなく可視化します。
ip route get 203.0.113.7 from 192.0.2.25
ip rule show許可するすべてのリフレクターアドレスについて、そのフローが運ぶと期待する送信元で経路クエリを実行し、次に除外した範囲についても実行して、代替が何を選ぶかを見ます。二つの答えを書き留めたポリシーと比べてください。意図しない形で異なるなら、ブラウザーの候補リストを解釈することなく修正点を見つけたことになります。