アプリのキルスイッチとファイアウォールのキルスイッチ：それぞれ何を止めるか

機能一覧に並ぶキルスイッチは、トンネルが落ちたときに何が起きるかをほとんど教えてくれません。ある実装は選んだプロセスを閉じ、別の実装はオペレーティングシステムの境界でパケットフィルターを入れ、三つ目は単に再接続を試みるだけです。違いが出るのは障害後の数秒間であり、設定画面ではありません。次の確認を順にたどり、正直に答えられない最初の項目で止めてください。そこが実際の守備範囲の終わりです。

まず強制の仕組みを見極める

プロセスの終了はアプリケーションのライフサイクル機能です。検出されたトンネル障害の後、選ばれたプログラムを見つけて閉じます。メインプロセス以外は残ります。補助サービス、バックグラウンド同期、一秒後に起動したアプリには、それぞれ独自のライフサイクルとタイミングがあります。

パケットフィルタリングはオペレーティングシステムの機能です。許可された経路に従わない通信を拒否します。より強い約束ですが、ルールが実際に一致する範囲でのみ有効です。アドレスファミリー、インターフェース、除外アプリ、例外がそれを決め、クライアントの表示ラベルではありません。

ブロックはクライアントより長く残るか

この順で四つの問いを立てます。クラッシュ時、手動終了時、ログアウト時、再起動時に何が起きるか。クライアント自身が管理するルールは、通常は正常終了時に削除され、しばしば クラッシュ後に残ります。プラットフォームの保管庫にインストールされたルールは逆に振る舞うことがあり、クライアントも、時にはアンインストールも生き延びます。

長いダウンロードの途中でクライアントを終了し、転送が止まるか続くかを見ます。

定番の穴を探す

一つ目はIPv6です。IPv4アドレス向けに書かれたルールはIPv6の通信をそのまま通し、多くのクライアントはv4側しか書きません。二つ目はインターフェースです。USBテザリング、二つ目のWi-Fiアダプター、携帯モデムは、主要な接続に限定したルールに含まれないことがあります。 除外アプリ とローカルネットワークの例外が三つ目です。

Windowsではトグルを信じる代わりに、インストールされたルールを読めます。Get-NetFirewallRule -DisplayName '*VPN*' と netsh wfp show filters はどちらも何が存在するかを示します。Linuxでは iptables -S、ip6tables -S、nft list ruleset が一般的なケースを押さえており、三つを比べることが要点です。

DNSがいつもの漏れ口

UDP 53 を開けたままTCPを止めると、どんなホスト名の問い合わせにも答えてしまう、非常にもっともらしいキルスイッチになります。DNSが別インターフェースのリゾルバーに渡されている場合や、クライアントがv4だけを止め、リゾルバーにはv6で届く場合も同じです。

トンネルを落とした状態で、既知の名前を一つ解決し、応答が返るかを見ます。返るなら、ステータスアイコンが何を言おうと、通信は完全には止まっていません。

切り替えではなく遷移を試す

VPNを自分のメニューから切るのは正常終了であり、正常なケースはどの実装も得意です。重要なのは乱暴な遷移です。トンネルのプロセスを殺し、ネットワークを抜き、サーバーが応答をやめるようにします。そのうえで要求を始め、失敗するのか、黙って物理リンクを使うのかを見ます。

一台のノートPCの結果はスマートフォンやルーターには当てはまりません。プラットフォームAPIも既定値も異なり、Androidでは差が顕著です。ブロック付きの常時接続はクライアントではなくシステムが強制するため、クライアントが動かないときも効き続けます。AndroidのVPNガイダンス がその分かれ目を説明しています。

戻り道を確保する

システムレベルのブロックには逆の失敗モードがあります。クライアントより長生きするフィルターは、アンインストール後にマシンを完全にネットワークなしにすることがあり、原因の分からないサポート連絡になります。プラットフォームのルールを書くキルスイッチを有効にする前に、それがどう外されるかを記録し、ベンダーの修復手順を見つけられる場所に置いておきます。

クラッシュ、IPv6、DNS、遷移の確認に答えられないなら、そのクライアントは既知の穴を持つアプリレベルのスイッチとして扱い、それに合わせて計画してください。