追加ソフトなしの Windows キルスイッチ：プロファイルかルートか

ファイアウォールのプロファイルはネットワークの区分に従い、ルートはアダプターに従う。両者を比べ、トンネルが消えてアイコンが嘘をつく障害時の挙動を試す。

ダウンロードの途中でクライアントが落ち、トレイのアイコンが消える。転送は自宅の回線のまま続いている。この順序こそがキルスイッチの存在理由であり、Windows は別製品なしでもそれに近いことを実現できる。

知っておく価値のある方法は二つある。失敗する場所が異なり、どちらも完全な答えではない。

方法一：プログラムを一つのプロファイルだけで許可する

Windows ファイアウォールは規則を Domain、Private、Public の各プロファイルに限定する。コツは、トンネルのアダプターに一方の区分を、物理アダプターに他方の区分を与えることだ。そのうえで、保護したいプログラムをトンネルのプロファイルでは許可し、それ以外の場所では遮断する送信規則を書く。ファイアウォールが読むのは区分であり、アダプター名ではない。

まず VPN 接続を Private に、物理ネットワークを Public に設定する。次に、望まないプロファイルに適用される遮断規則をプログラムに追加する。その後、規則が従うこの割り当てを Get-NetConnectionProfile で確認する。

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public

New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private

弱点は構造的だ。プロファイル規則は区分に従うため、Windows がホテルのネットワークを再分類すると遮断が効かなくなることがある。そのとき規則一覧には何の変化も現れない。

方法二：物理の既定ルートを削除する

ルートによる方法はより乱暴で、監査はずっと簡単だ。物理ゲートウェイを控え、VPN により低いメトリックの既定ルートを入れさせ、そのうえで物理の既定ルートを削除する。そうすれば他に通信を運べるものはなくなる。

route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"

クライアントが落ちれば、VPN のルートはそのアダプターとともに消える。機械は漏えいする代わりにオフラインになり、これこそがキルスイッチの生むべき結果だ。

一週間もつかどうかを決める細部が二つある。リンクが揺れるたびに DHCP がゲートウェイを戻してしまう。固定アドレスの物理アダプターならその驚きは避けられる。VPN サーバー自身のアドレスも到達可能なままにしておく必要がある。そのホスト経路がなければ、遮断を引き起こした切断のあとクライアントは二度と再接続できない。

方法三：ゲートウェイなし、永続ホストルートを一つだけ

第三の選択肢は、アダプターの設定からゲートウェイを消すことから始まる。次に VPN の端点への永続ルート一本がそれを置き換える。以後、トンネルが上がるまで機械はサーバーとだけ話せる。

route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44

ゲートウェイを戻せば通常のインターネットが戻り、これがきれいなオン・オフのスイッチになる。インターフェースのイベントを監視するスクリプトには依存しない。ネットワークがどう区分されるかも関係ない。

代償は、トンネルが落ちている間の完全な孤立だ。更新は止まり、この作業を始めさせたダウンロード自体も止まる。仕事用のノートなら多くの場合それが正しく、個人の機械なら意図して選ぶ判断になる。

地球儀アイコンが何も証明しない理由

Windows は Microsoft の端点への検査で到達性を報告する。その検査はあなたのトンネルについては何も語らない。接続中のトンネルが「インターネットなし」と報告する地球儀の裏に座ることもあり、死んだトンネルが健全な接続を示すこともある。

クライアントのプロセスを落として試す。そのうえで番号を使って公開アドレスへの到達を試み、名前の問い合わせはキャッシュから答えられうるので、アイコンも DNS の応答も証拠にはならない。

実際の切断後に記録すべきこと

試験は単発の確認ではなく順序として実行する。切断ではなくプロセスを落とし、そのうえで両方のアドレス体系で数値アドレスを試す。その後クライアントを戻し、残したルートで自分のサーバーにまだ届くことを確認する。

taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"

スリープ後、Wi-Fi 変更後、有線から無線への切り替え後に同じ順序を繰り返す。プロファイル方式と DHCP の挙動が同時に破綻するのはこうした切り替えの場面だ。机の上で成り立つ規則がホテルでも成り立つとは限らない。

すべての規則とルートの隣に戻し方を書いておく。Microsoft は送信規則の作成をWindows ファイアウォールの規則のリファレンスで文書化しており、画面写真だけの手順より良い出典だ。

関連記事