トンネルから除外したアプリを、キルスイッチは遮断するのか？

キルスイッチが有効で、アプリが意図的にトンネルから除外され、二つの要件が今は矛盾しています。一方はトンネル以外から何も出してはならないと言い、もう一方はこのプログラムを直接通せと言います。競合の解決方法はクライアントごとに違い、設定画面がどちらの規則を優先するかを説明していることはほとんどありません。どのラベルも信じる前に、アプリごとの方針を書き留めてください。

二つの方針、一つの機械

キルスイッチは、トンネルが通信を保護していないときに通信を止めるという、障害についての約束です。分割トンネルは、これらのプログラムや宛先がトンネルを使い、それ以外は使わないという、選択についての約束です。二つ目の約束は、一つ目の約束が判断しなければならない通信を生みます。どちらの約束も間違いではなく、ただ別々の人が別々の脅威のために書いただけです。

結果は三通りあり、そのうち一つだけが導入の意図です。除外したアプリは障害中も直接のまま残り、分割を守ってキルスイッチを破るかもしれません。ほかのすべてと一緒に遮断され、キルスイッチを守って分割を破るかもしれません。あるいは、インターフェースが消えた後にプラットフォームが規則をどう評価するかによって、ときどきだけ遮断されるかもしれません。チケットを生むのは最後のケースです。

規則より先にアプリ一覧を書く

トンネルを使うべきプログラム、直接通すべきプログラム、どちらの一覧にも決して現れてはならない名前や宛先を列挙してください。リゾルバの挙動と IPv6 側は、どちらもページの通信とは違う方針に従うことがあるため別に含めてください。

アプリごとの規則は通常、実行ファイルやパッケージに一致し、その中のプロファイルには一致しません。ブラウザのプロファイル、プライベートウィンドウ、拡張機能は独自のネットワーク識別子を持たないため、プロセスが受け取ったものをそのまま引き継ぎます。そのブラウザが起動した補助プロセスは、同じ規則をまったく引き継がないことがあります。

必要なのは一覧ではなく二つで、トンネルが運ぶべきものと、どんな理由でもその外に出してはならないものです。両方に載るアプリは実装の詳細ではなく要件の衝突であり、クライアントを設定する前に決着させる必要があります。

障害中にクライアントがすること

実装によっては障害中に除外アプリを遮断し、再接続時にアクセスを戻します。別の実装は直接経路をずっと維持し、これは分割と整合しますが、安全特性としては弱くなります。プラットフォーム側のロックダウンはクライアントのアプリごとの選択を完全に上書きできます。この違いは見た目ではなく、除外アプリが方針の例外なのか穴なのかを決めます。

Android の常時接続 VPN と、VPN なしの接続を遮断するオプションの組み合わせが最も明確な例で、ロックダウンを強制するのはクライアントではなくプラットフォームであり、トンネルが落ちている間は除外パッケージもほかのすべてと一緒に遮断されます。アプリごとの除外を自前のドライバで適用するデスクトップクライアントは、そもそもそのプロセスの通信を所有していなかったため、通常、除外したプロセスを物理インターフェースに残します。どちらの挙動も擁護できますが、除外アプリを使い続けられるべきだという要件に合うのは片方だけです。結果を解釈する前に、どの構成要素が規則を強制しているかを尋ねてください。

目の前のオペレーティングシステムの挙動を読み、他所の同じ名前の設定を読まないでください。強制の API は異なり、チェックボックス一つがデスクトップとスマートフォンでまったく違う意味を持つことがあります。バージョンも重要で、ロックダウンの制御は Android のリリースごとに画面の間を移ってきましたし、クライアント側の除外一覧はプラットフォームのロックダウンと同じ制御ではありません。

三つの時点：トンネル稼働中、トンネル停止中、再接続後

無害な要求を、トンネルが動いているとき、気にしている障害の最中、再接続した後の三つの時点で使います。ブラウザの結果一つでは、除外アプリの挙動を確かめられません。

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

出口アドレスはどの経路を通ったかを示し、明示的なインターフェース試験はトンネルが唯一の出口のときに何が起きるかを示します。どれかを実行する前に、そうしないと出力が後から解釈されてしまうので、各行の横に期待する結果を書いてください。

除外アプリがオフラインになったら、その修正は試験していた区別を壊すため、広いファイアウォール許可を足す前に方針の優先順位を調べてください。直接のままなら、それが文書化された例外であり、偶然の後退ではないことを確かめてください。端末全体に対する厳格な要件なら、手作業で試せるまで例外一覧を短くしてください。