VPNキャプチャ：tun0の内側パケットとeth0の外側エンベロープ

VPNホストでのキャプチャは、一つのものだけを記録するわけではない。カーネルはパケットを二度露出する——物理アダプターでは包まれ、トンネルデバイスでは開かれた形だ。インターフェースを選ぶことは、どちらの物語を読むかを選ぶことだ。キャプチャが何を証明するかという議論の多くは、実際にはどちらの物語を集めたかという議論である。

カプセル化が二つの見え方を作る

トンネルはアプリケーションが生成したパケットを取り、宛先をVPNサーバーとする新しいパケットの内側に置く。内側の形はtun0、wg0、あるいはクライアントが作った任意のデバイスに現れる。外側の形は、それをネットワークへ運ぶアダプターに現れる。どちらの形も正当であり、異なる問いに答える。二つはヘッダーも読み手も異なるので、それぞれを別々に集めるべきだ。

sudo tcpdump -i tun0 -n -s 0
sudo tcpdump -i eth0 -n host 198.51.100.20 and udp port 51820

この比較には疑似インターフェースanyが不適切だ。転送されたパケットは二度記録され得るし、ローカルで生成されたパケットは両方の形で現れるため、計数が膨らむ。数値が不可能に見えるなら、トンネルを責める前にインターフェースを確認すること。

トンネルの内側ではパケットは普通だ

トンネルデバイス上で見えるのは、アプリケーションがカーネルに送るよう求めたものだ。宛先アドレス、ポート、DNS名、TLSサーバー名、サイズ、タイミングがすべてそこにある。TLSペイロードはアプリケーション自身のセッションで暗号化されたままなので、キャプチャはページ内容を明かさない。平文のDNSクエリは、その運び手が暗号化されていても、もともと保護されていなかったのだからここでは見える。

暗号化DNSはその一つの可視フィールドを消す。宛先アドレス、バイト数、リズムは、クエリではなくフローの性質だから隠さない。

外側ではエンベロープとその形だけ

物理アダプターは自分とサーバーのアドレス、ポート、パケットサイズ、タイミングを示す。内側で運ばれる宛先は見えないが、その形から推測できる場合がある。サイズとリズムは、どれも名指しせずに動画ストリーム、大容量転送、チャットセッションを示唆し得る。近くの観測者はほぼ同じ眺めを得るため、トンネルが自分の存在を宣伝しながらサイトを隠せる理由も説明できる。

その主張はルーティング次第だ。より狭いルート、トンネルに入らないIPv6の既定、物理インターフェースに束縛されたプロセスは、通信をエンベロープの外に置く。キャプチャから結論を出す前に実際のルートを読むこと。

ピアアドレスとキャプチャの衛生

TCPモードのOpenVPNは確立済みのソケットを保つため、ソケット表がピアを示せる。UDPモードのOpenVPNはソケットを未接続のままにすることが多く、ssはローカル側しか表示しないかもしれない。代わりにプロファイルのremote、詳細なクライアントログ、エンドポイントへのルートを読むこと。WireGuardはエンドポイントと最後のハンドシェイクを直接報告する。

wg show
ss -tunp | grep 51820

キャプチャファイルはそれを作ったセッションより長く残る。コピーでき、ローカルアクセスを持つ誰でも読める可能性がある。調査に必要なものだけを残し、権限を制限し、作業が終わったら削除すること。

共有可能なキャプチャは、どのインターフェースがいつ作ったかを示すべきだ。その注記がなければ、次の読み手はどの層を見ているのか推測するしかない。