eth0 のトラフィックは VPN トンネルの漏えいを意味しない

トンネルが上がっているのに eth0 でパブリックアドレスが見えると、何かが漏れた証拠のように感じます。たいていは逆です。トンネル自身のパケットはサーバーに届くためにそのアダプターを通過しなければならず、ふつうの UDP や TCP の流れに見えます。内側のパケットはトンネルデバイスにしか現れません。両者を区別するのは外装を読むという話であり、バイト数を信じる話ではありません。

トンネルのパケットも依然として回線を渡る

トンネルはインターフェースであり、回線ではありません。クライアントは内側のパケットを取り出し、包んで、その結果をプロファイルのサーバーアドレスとポートへ送ります。物理アダプターでは包みが見え、トンネルデバイスでは包まれたものが見えます。

UDP モードでは外側の流れは各方向でアドレスとポートの組がひとつだけなので、健全なトンネルは eth0 ではほとんど退屈に見えます。まず探すべきはそのひとつの組です。

一度にひとつのインターフェースをキャプチャする

カウントを比較するつもりなら、一度にひとつのインターフェースだけをキャプチャしてください。any という擬似インターフェースはすべてのデバイスをまとめて集めるため、転送されたパケットは入口と出口の両方に現れ、ローカルで生成されたパケットは異なる二つの形で二度現れます。パケット数が同じでもバイト数が違うのは正常です。外装のほうが運ぶ中身より大きいからです。ARP、DHCP、IPv6 ルーター広告はローカルリンクに属し、あなたのアプリケーションについては何も語りません。

sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194

アドレスとポートはプロファイル自身の値に置き換えてください。その流れが安定していれば、トンネルは何かを運んでいます。

カーネルにどのデバイスを選ぶか尋ねる

カーネルにどのデバイスを選ぶかを尋ね、次に回線上で確認します。経路の問い合わせが決定であり、キャプチャはその決定が守られた証拠です。両者は別の問いに答えており、どちらも必要です。

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

よくある発見は分かれた結果です。プロファイルが IPv4 の経路しか押し込んでいないため、IPv4 はトンネルへ、IPv6 は物理アダプターへ向かいます。これは実際の漏えいで、IPv4 だけのキャプチャでは見えません。IPv6 で絞り込み、サーバーでも link-local でもないアドレスに注目してください。

接続の前と後に両方の問い合わせを実行し、クライアントが実際に何を変えたかを見てください。二回の実行の差がクライアントの本当の効果です。

キャプチャが本当に漏えいである場合

キャプチャが真実を語ることもあります。ひとつのプレフィックスをトンネルの外へ送る狭い経路、クライアントが除外するよう指示されたサブネット、トンネルのポリシーより前に動くファイアウォールの許可は、いずれもトラフィックを平文で回線に載せます。プロセスグループに一致するルールも意図的な例外かもしれません。不具合と呼ぶ前に、そのインターフェースと宛先の範囲を読んでください。

直すべきは経路か除外であり、ファイアウォールではありません。そのうえで新しい接続からもう一度キャプチャし、IPv4 と IPv6 を別々に確認してください。片方を直してももう片方については何も言えないからです。tcpdump のマニュアルには、上で使ったインターフェースと方向のセレクターが載っています。