VPNアプリがクラッシュ、キルスイッチはまだ効いているか

クライアントのウィンドウが消え、トレイのアイコンも消え、ブラウザが読み込むかどうかという、ユーザーが最初に見る光景から始めましょう。その観察だけでは、ブロックが生き残ったかは分かりません。答えは、どのコンポーネントがルールを持っているか、そのコンポーネントがウィンドウと一緒に死んだか、プラットフォームが強制をアプリの外に置いているかで変わります。ウィンドウからプロセスへ、次にファイアウォールへ、次に実際の経路へと進んでください。

まず再起動は避けてください、再起動はたいてい証拠を壊すからです。

まだ動いているものから始める

何かに触れる前にプロセス一覧を開きます。デスクトップクライアントは通常、UIプロセスとサービスまたはデーモンに分かれ、前者のクラッシュが後者を必ず止めるわけではありません。Windowsではサービスが一覧に残っているかもしれませんし、Linuxではユニットがまだアクティブかもしれませんし、Androidでは同意が与えられた時点でトンネルはシステムのものです。この三つの事実をこの順に読んでください。

デーモンが生きていればトンネルも生きている可能性が高く、消えたウィンドウは見た目だけの問題です。

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

ブロックはアプリではなく強制している側で読む

クライアントがファイアウォールのルールを挿入してキルスイッチを実装している場合、そのルールはOSに属し、作成したプロセスの終了後も残ります。その場合クラッシュは、オフにするインターフェースがないままブロックされた状態を残し、保護というより壊れたネットワークに見えます。逆にブロックがクライアント自身のパケット経路の内側にあるなら、プロセスを殺すと同じ瞬間にブロックが消えます。

Androidはこれをまた別に扱い、lockdown付きのalways-on VPNはプラットフォームの設定なので、ブロックはアプリのプロセスとは無関係に残り、システムがサービスを再起動することがあります。デスクトップクライアントと同じだと決めつけず、正確な挙動はプラットフォームのドキュメントで確認してください。

正常終了とクラッシュを見分ける

通常のQuitはクライアントの終了経路を実行し、意図的にルールを削除してトンネルを閉じます。クラッシュはその経路を飛ばし、強制側がすでにインストールしたものを残します。違いは、プロセス終了に対するルールのタイムスタンプと、所有者のいない古いトンネルインターフェースが残っているかどうかに表れます。

この違いが復旧方法を決めますが、正常終了なら新しい接続が必要かもしれませんし、クラッシュなら残ったルールをクライアントのサポートされた修復操作で削除する必要があるかもしれません。

他の制御を壊さずに復旧する

クライアントを文書化された手順で再起動し、要件の両半分、つまりトンネルが通信を運び、ブロックが必要なときにまだ適用されることを確認します。接続を取り戻すためにファイアウォール全体をフラッシュすると無関係な制御も消えるので、その取引はめったに割に合いません。

クラッシュが繰り返される場合は、クライアントのバージョン、プラットフォームのビルド、ベンダーが求める範囲のログを集めてください。クラッシュ報告に別アカウントのクライアントプロファイル、秘密鍵、完全な接続ログは不要で、含めるとサポート案件がデータ処理の問題になります。

一度のクラッシュは漏えいの証拠ではありません。証拠とは、ポリシーが防ぐはずだった経路から出ていくパケットが、クライアントが落ちていた瞬間に観測されたものです。無害な宛先で意図的に試し、どの強制層が持ちこたえたかを書き留めてください。