VPNをすり抜けるIPv6トラフィック：漏れている経路を見つける

二つのテストページが食い違います。一方はトンネル経由でプロバイダーのアドレスを報告し、もう一方は自宅のプレフィックスを報告するため、VPNが漏れているという結論は明白に見えます。しかしその結論は一段階を飛ばしています。二つの報告は二つの異なる経路判定を働かせたのであり、トンネルに入るべきだったのはそのうち片方だけです。穴はたいてい実在し、壊れたトンネルではなくカバレッジの問題です。三つの問いで決着します。どのフローが実際に出たのか、カーネルがそれにどの経路を選んだのか、クライアントがどの挙動を意図していたのかです。

その順序で作業します。順序を変えて答えると、本当の答えはIPv6経路が一度も導入されなかったことなのに、クライアントに不具合があるのかという長い議論になります。

どのフローが実際に出たのか、どのアダプター上で

まず、使ったファミリーを明示するテストから始め、次にアプリケーション、接続しているネットワーク、有効なプロファイル、そして接続がIPv6を提供しているかどうかを書き留めます。この四つの事実が二回の実行を比較可能にし、四つ目は忘れられがちです。v6プレフィックスのないネットワークはv6を漏らせませんし、後からプレフィックスを追加するネットワークは答えを変えます。

ページを読み込んで結果を読むのではなく、ファミリーごとに一つずつ要求を送ります。一つのページがv6とv4のリソースを混在させることがあり、バックグラウンドのプロセスは目の前のタブと違う振る舞いをすることがあり、キャッシュされた応答は検証したいネットワーク変更より長く生き残ることがあります。テストする宛先を固定して記録し、繰り返しの実行が同じものを測るようにします。

カーネルが選んだ経路を読む

経路テーブルはブラウザーが答えられない問いに答えます。特定の宛先がどこへ向かうかをシステムに尋ね、表示されるデフォルトだけでなくポリシールールも含めます。どちらもそれを上書きできるからです。

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

より具体的なプレフィックスが、一つの宛先だけがトンネルの外に残り他はすべて内側にとどまる通常の理由であり、ポリシールールはどの経路よりも高い優先度で同じことをできます。メトリックも読んでください。同じプレフィックスの二つの項目は、画面の順序ではなくメトリックで決まります。Windowsでは同等の一覧は Get-NetRoute -AddressFamily IPv6 で、意思決定の順序に合わせてメトリックで並べ替えます。表の上で正しく見えるルールでも、番号の小さいポリシールールに負けることがあり、だからルールの一覧は経路の一覧と同じ呼吸で扱うべきです。

クライアントのIPv6ポリシーはどこから来るのか

クライアントはv6をトンネル経由で運ぶように作ることも、それを拒否するようにも、名前付きの例外を許可するようにも作れます。これら三つの意図は三つの異なる正しい結果を生みます。観測を漏れと呼ぶ前にプロファイルとクライアント自身の文書を読んでください。v6を遮断しながらOSが物理リンクで近隣探索を送り続けるクライアントは、設計どおりに動いているからです。

トンネルから意図的に除外されたアプリケーションは、トンネルが一度も運ばなかったファミリーとは別のケースです。前者は一つのプログラムについての決定であり、後者はカバレッジの穴であり、修理の仕方もそれに応じて変わります。存在するはずのなかった経路を探す前に、クライアントの除外プログラム一覧を読んでください。

狭い観測、表が食い違うとき

経路の検索が曖昧なときは、ホスト上での一つのインターフェース観測が決着をつけられますが、それは問いに狙いを定めている場合だけです。VPNエンドポイント自体へのトラフィックは設計上物理アダプターを通ります。重要なのは、まったく別の場所を宛先とするアプリケーションのフローもそこに現れるかどうかです。すべてを収集するのではなく、テストする宛先にキャプチャーを絞ってください。

広いキャプチャーは、その一つの問いが必要とするよりはるかに多くの個人トラフィックを露出します。また、気にしているフローが無関係な接続の流れに埋もれて届くため、答えも不明瞭になります。テストした宛先に絞り、数個のパケットで止め、キャプチャーを削除してください。

穴を閉じる三つの方法

ファミリーをトンネル経由で運ぶか、トンネルが運べないときにクライアントで遮断するか、所有者とレビュー日を添えた意図的な例外を記録します。どれも擁護できますが、擁護できないのは選択を暗黙のままにすることです。暗黙の選択こそが漏れの正体だからです。トンネルにv6の出口がまったくないなら、クライアントでv6を拒否するのは正直でもあり検証可能でもあります。大事なのは、選択が次の人が見つけられる場所に書かれていることであり、半年後に挙動から推測されることではありません。

再接続の後とネットワーク間を移動した後にもう一度確認してください。前のリンク向けに導入された経路は変更を生き延びることがあります。そのうえで宛先、選ばれた経路、クライアントのポリシー、テストが使ったファミリーを記録し、次の人が導出し直すのではなく決定を読めるようにします。RFC 7359 はデュアルスタックの漏れをバグではなく設計上の問題として文書化しており、動作するv4トンネルがすべてを覆うと誰かが主張したときに引くべき参照です。