VPNキルスイッチ：どの通信をいつ遮断するか
再接続はトンネルを復旧させますが、キルスイッチはトンネルが失われている間の扱いを決めます。切断、手動の切断、アプリ終了、ネットワーク切り替えを別々に試してください。
二つの機能は同じ言葉で説明されますが、役割は違います。自動再接続はトンネルを戻そうとし、一秒以内に成功することもありますが、その隙間では要求が失敗します。キルスイッチはその隙間に通信をどう扱うかを決めます。両者を一つの設定として読むと、ポリシーではなくアイコンを信じる結果になります。
遮断と再接続は別々の判断
あるクライアントは予期しない切断のときだけ遮断し、その後で再接続して遮断を解除します。別のクライアントは手動で設定を変えるまでシステム全体の遮断を保ち、三つ目は意図的な切断を通常のアクセスへ戻す許可とみなします。これは三つの異なる挙動であり、ベンダーの文書は自分のビルドがどれかを示しています。
プロファイルを読み込んでもこの問いは決まりません。同じサーバープロファイルが逆の遮断挙動を持つ二つのクライアントに読み込まれます。プロファイルは設定を運ぶのであって、約束を運ぶのではないからです。デスクトップのチェックボックスとスマートフォンのスイッチが同じ名前でも別の規則を実装しうる理由もそこにあります。自分のプラットフォームのコントロールに添えられた説明を読み、そのうえで実際の動作を試してください。
同じプロファイルが二つのクライアントで違う挙動になる
OpenVPN Connect アプリの設定は、クライアントが一時停止または再接続中と報告している間だけ通常の通信を保留するトンネルモードを説明しており、あらゆるプラットフォームのあらゆる事象に対する一般的な約束より狭いものです。製品名ではなく、列挙された状態を読んでください。あるクライアントのビルド向けに書かれた説明は、別のベンダーのクライアントには移りません。
Android は二つのコントロールに同じ言葉を使いますが、常時接続 VPN と VPN なしの接続の遮断は別々に文書化されています。同じ名前のチェックボックスを持つデスクトップのクライアントは、どちらよりも狭い、あるいは広い動作を実装しているかもしれません。二つのメニューに同じラベルがあることを、両方の説明を読むまでは偶然とみなしてください。管理された端末は第三の層を加えます。端末プロファイルは利用者が見ることも取り消すこともできない設定を強制できるからです。
似て見えるプラットフォーム設定は同等ではない
目に見えるコントロールと、実際に適用されるポリシーを比べてください。管理された端末では、見えているスイッチが灰色になっていたり、上位のプロファイルが逆を強制しているのに有効になっていたりします。ローカルではなく実効ポリシーを求め、回答を書面で受け取ってください。
何かを試す前に、各層が何を主張しているかを記録してください。両者はしばしば食い違い、試験が始まるとその食い違いは簡単に失われます。試験中に正しく遮断している端末が、誰も記録していない理由で遮断していることもあります。
一度に一つの事象を実行し、コードを記録する
一度に一つの事象だけを、無害な要求で試し、毎回の試行を新しい要求にしてください。すでにキャッシュされているかもしれないページではいけません。下のコマンドはトンネルを落とし、ページを要求し、インターフェースが戻ったかどうかを示します。
ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0表は各操作を、意味のある観察と残す価値のある証拠に対応づけます。制限時間内に失敗する要求は遮断が働いたことを示し、通る要求は通信が別の経路を見つけたことを示します。それは遮断の無効化ではなく除外経路かもしれません。意味のあるソフトウェア更新や経路ポリシーの変更のあとは、一連の試験をすべてやり直してください。どちらも、見える設定が動かないまま分岐を変えうるからです。最後に欲しいのは安心させるアイコンではなく、予測できる失敗の挙動です。
| What I do | What I watch | Evidence to keep |
|---|---|---|
| Bring the tunnel down by hand | Whether a fresh request fails at once | The HTTP code and the client state at that second |
| Choose Disconnect in the client | Whether ordinary access returns on purpose | The same request succeeding with no tunnel up |
| Quit the app, then reboot | Whether the block outlives the client | A request made from a clean boot |
| Move from Wi-Fi to cellular | Whether DNS and IPv6 follow the policy | The resolver answer, the route table and the code again |
例外、ゲストポータル、遮断にできないこと
ローカルネットワークへのアクセスはよくある例外で、約束の範囲を変えます。同じサブネットのプリンターには届くが他はすべて遮断する、という構成は家庭では妥当でも、ゲスト用ネットワークでは疑問が残ります。その例外を望むのかどうかを、事故が代わりに発見する前に決めてください。
厳格な遮断は、ゲスト用ネットワークのポータルへのサインインも厄介にします。ポータルはまさに、遮断が止めるために存在する直接の通信だからです。ネットワークを許可するためのサポートされた方法を覚え、ページが読み込まれるまでコントロールを切るのではなく、意図してポリシーを戻してください。リゾルバーの応答と経路表は、下のように同じメモに残します。キルスイッチにできないのはサービスを匿名にすることです。トンネルの外の通信を遮断しても、内側で何が起きているかは何も語らないからです。
resolvectl query example.com
ss -tunp | grep -v tun0