侵害されたホストでキルスイッチが何を守るかを検証する方法

キルスイッチを入れ、トンネルサーバーをオフラインにし、マシンがまだ何をするかを観察します。このテストは、ファイアウォールが実際に強制するものとあなたが想定していたものを分離し、結果が多くの製品ページの示唆より狭いので、実行する価値があります。キルスイッチが支配するのはネットワーク経路であり、端末上で既に動いているソフトウェアではありません。クライアントが fail-closed を主張するすべてのマシンでこの手順を実行しますが、所要時間は約十分です。

サーバーではなくクライアントから始める

強制の地点は、あなたが座っているホスト、つまりOSのファイアウォール、補助サービス、あるいはVPNクライアント自身のドライバーです。これが重要なのは、スイッチにできることすべてが、その層から見えるものに制限されるからです。ルーティング規則とマークで遮断を実装している場合、十分な権限を持つものは独自の規則を追加でき、カーネルのファイアウォールテーブルを使っている場合は同じ権限でテーブルを編集できます。暗号の強さはこの問題に一切関係しません。

したがって最初に確定すべきは、この端末のポリシーを誰が所有し、何を上書きできるかです。管理された業務マシンでは答えは通常組織のエンドポイントエージェントであり、個人用VPNはトンネルがどう設定されていてもその能力を奪いません。

第一段階：守っていると考える経路で遮断を確認する

クライアントではなく遠端でトンネルを落とす。そうすればクライアントは依然として接続すべきだと信じ、次に人が実際に試すことを試します：

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

望むのは迅速かつきれいに失敗するクライアントであり、ブラウザのタイムアウトまで固まるものではありません。固まるのは通常、拒否のない規則によってパケットが黙って破棄されているという意味で、それは許容できますが、クライアントが死んだインターフェースに向けた古いデフォルトルートを残したという意味でもあります。トンネルが落ちている間にルーティングテーブルを読み、トンネルデバイスを指したままのデフォルトルートと、新しい外向き接続だけを遮断するファイアウォール規則が別の状態であり、fail-closed なのは片方だけだと確認します。

クライアントの allow-LAN オプションをオンとオフにして同じコマンドを繰り返します。この切り替えが多くの驚きの住処であり、ポリシーの残りが閉じるために書かれていた経路を再び開きます。

第二段階：DNS と IPv6 を別々の経路として確認する

名前解決は、問い合わせがシステムリゾルバ以外から出ていけるため、ほとんどの実装を生き延びる隙間です。リゾルバ設定を無視するツールで問い合わせ、ついでに v6 側も確認します：

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

トンネルが落ちている状態で両方の名前問い合わせが空の答えを返すのが望ましい結果です。二番目の問い合わせが答えを返すなら、ハードコードされたリゾルバアドレスに到達でき、トンネルはマシンからの唯一の出口ではありません。v6 の要求だけが成功するなら、ポリシーは IPv4 を覆い IPv6 を無視しており、別のアドレスファミリーでの同じ漏洩です。

ブラウザはこれを外から読みにくくします。DNS over HTTPS 向けに設定されたブラウザは問い合わせを HTTPS 要求で解決するため、問い合わせはその端点へのポート 443 が遮断される分だけ遮断され、ポリシーがローカルサブネットを許可するホストではその要求が LAN 上のリゾルバに依然として届きます。

第三段階：ネットワークの露出と端点の露出を分ける

ここからは、どのファイアウォール規則も届かない部分です。キルスイッチはマシンからの経路を遮断しますが、マシン上のソフトウェアが暗号化前にデータを読むのを止めず、そのソフトウェアがトンネルを正当に使うのも止めません。キーロガー、悪意ある拡張機能、解錠したままの画面、広い権限を持つ同期クライアントなどは、いずれもスイッチが喜んで許可する接続で情報を運びます。

同じことは、雇用主が意図的に導入した監視ソフトウェアにも当てはまります。経路を遮断してもそれは消えず、新しい VPN サーバーを買うことも修復ではありませんが、それは露出がトンネルの上流にあるからです。

クラウドアカウントにアップロードするクリップボードマネージャーは、この点を鋭く示します。通信は暗号化され、宛先は許可され、キルスイッチはその間ずっと健全な状態を報告します。

第四段階：テストが支える主張を書く

遮断テストの後、どのアプリが失敗し、どの経路が止まり、DNS と IPv6 がどう振る舞い、トンネルが落ちたときに遮断が保たれたかという具体的な事実を述べられます。OS がきれいだとは言えませんし、遠端のサービスがログインを秘密に保つとも言えません。

二つの問題を切り離し、それぞれに独自の制御を与えます：

• キルスイッチ：定義された失敗要件であり、クライアント更新のたびに繰り返す遮断テストで検証します。
• 端末の信頼：サポートされた更新、信頼できる提供元からのエンドポイント保護、説明のつかない権限と認証要求の見直し。
• インシデント：侵害が疑われるときはプラットフォームまたは組織の手順に従い、新しいサーバーを清掃の手順とみなしません。
• 開示：助けを求めるときは、ログやスクリーンショットが接続と同じ秘密を運ぶため、秘密鍵や診断アーカイブ全体を貼り付けません。

次の更新の後に同じ手順を再度実行します。それはキルスイッチがバージョンとともに動く設定であり、テストだけが、頼っている挙動が今も得られている挙動であることを示す唯一の証拠だからです。