トンネル分割が機能しているか検証する: 単一の IP 結果はテストではない

IP アドレスを表示する一枚のブラウザページは、トンネル分割についてほとんど何も証明しない。見えているアドレスは間違った理由で正しいかもしれず、除外されたフローはそれでは決して試されない。テストの前に期待する結果を書き出しておく：どのアプリケーションや宛先がトンネルを使うべきか、どれが直接接続のままであるべきか、トンネルが失敗したときに何が止まるべきか。その計画がなければ、もっともらしい数字はどれも成功に見える。

神話: アドレス検索はカバレッジを証明する

IP の確認が答える問いは、ある時点で一つのアプリケーションから外の世界が何を見るか、という一つだけである。社内プレフィックス、二つ目のブラウザプロファイル、内部的に解決されるべき名前については何も語らない。障害についても何も語らず、障害こそ、本番で壊れるトンネル分割設計の半分である。

アドレスのページはルート、リゾルバ、障害ポリシーも示せない。これを一つの観察として扱い、判定として扱わないこと。

含まれるフローと除外されるフローを試す

含まれるべきアプリケーションから、またはトンネルを通ると想定しているプレフィックスへ無害な要求を送り、送信元、宛先、アドレスファミリ、観察された経路を記録する。直接接続のままであるべきフローについても同じことをする。除外側こそ人々が飛ばしがちな側であり、分割が故意であって偶然でないことを示す唯一の証拠だ。補助プロセスは別のポリシー ID を持つことがあるので、ソケットを所有するプロセスで試すこと。

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

だからこそ、誤ったアプリケーションでのテストは設計の意図と逆の結果を示しうる。結論を出す前に、両側について四つのフィールドを書き出すこと。

DNS と障害時の動作を加える

システムのリゾルバとアプリが使うリゾルバに問い合わせ、その答えをサイトが報告する出口アドレスと比べる。二つの層は設計上食い違うことがあるし、ブラウザの検索一回では OS のポリシーを試したことにならない。シェルを使えば比較を繰り返せる：トンネルを故意に切り、次にブラウザがキャッシュしていない要求を送り、キャッシュから返るページがフォールバックの向きを何も語らないことを確かめる。設計が予測したことではなく、実際に起きたことを記録すること。

curl -s https://ifconfig.me
nslookup intranet.example

閉じる方向に失敗する分割トンネルと、開く方向に失敗する分割トンネルは、故意にトンネルを切るまで同じに見える。観察した動作を記録し、期待した動作を記録しないこと。

状態が変わったら繰り返す

再接続、ネットワーク切り替え、関連するアプリケーション更新の後に、同じ観察を繰り返す。保存された除外は、もう存在しない経路やアプリケーション ID を指したままになり、設計は静かに文書と合わなくなる。この三つの出来事がトンネル分割のずれる場所であり、どれも安く再テストできる。導入時に一度だけ走るテストは、もう存在しない構成を説明している。

結果が違うなら、複数の設定を一度に変える前に、ルールの所有者と処理段階を突き止める。五つのものを変えて一つの結果を見るのは診断ではなく、新しい構成である。

結果が示すべきこと

観察を、実際にテストしたポリシーとクライアントのバージョンに結びつける。目標は、この導入が自称するカバレッジに合っていることを示すことであり、将来のすべてのアプリケーションがプライベートになることを示すことではない。これはより狭い主張であり、証拠で本当に支えられる主張でもある。主張、バージョン、四つのフィールドの結果を変更記録に書くこと。

そうすれば次のレビュー担当者は、設計が変わったのかテストが変わったのかを判断できる。両側、リゾルバの分割、障害時の動作が最初に書き出した内容と一致したとき、トンネル分割は検証されたことになる。単一の IP 結果はそのどれも検証しない。