終了と切断の違い：VPN で異なる二つの結果

メニューには切断があり、ウィンドウには閉じるボタンがあり、タスクマネージャーにはタスクの終了があります。どれも VPN を止める方法に見えますが、それぞれがマシンを異なる状態に残す可能性があります。一方はトンネルを止めてブロックを残し、もう一方は正常終了の一環としてすべてを片付け、三つ目はバックグラウンドのコンポーネントが動き続けたまま画面だけを隠すかもしれません。これらを同義語として扱うことが、プライバシー試験が何が起きたかについて誤った結論に至る道です。

どれがどれなのかを知る唯一の確実な手がかりは、クライアントのドキュメントです。

四つの操作、おそらく四つの挙動

切断は通常、クライアントを常駐させたままトンネルを解体するため、サービス、トレイのコンポーネント、キルスイッチのルールがクリック後も残ることがあります。その結果、多くのクライアントは、クライアントが存在する間は端末を直接アクセスに戻してはならないというポリシーに従って通信のブロックを続けます。この挙動は壊れたネットワークに見えますが、意図的な保護です。

終了はアプリケーションを終わらせるためのもので、行儀のよいクライアントは終了時に自分のルールを削除します。そうではなく、ポリシーを適用する別のヘルパーを残す設計もあり、それは欠陥ではなく選択です。ウィンドウを閉じるのはトンネルへの影響が定義されていない画面操作であり、提供されている場合の一時停止は独自のルールを持つ四つ目の挙動です。

サーバー側の障害はまったく別の五つ目の経路であり、利用者が実際に最もよく遭遇するのはこちらです。

各操作の前後で状態を読み取る

操作の前にプロセス一覧、サービスの状態、ファイアウォールのルールを記録し、直後に同じ記録を繰り返します。二つの一覧を比べれば、画面の説明に頼らずに、その操作が実際に何をしたのかが分かります。

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

ルールがプロセスと一緒に消えたなら、それはクライアントが持っていたものです。プロセスが消えてもルールが残っているなら、別の何かがポリシーを適用していますので、そのコンポーネントを突き止めることが変更より先になります。止まった画面はシステムサービスについて何も語らないため、同じ瞬間にサービスの状態も記録してください。

手動の切断はクラッシュではない

切断は意図された終了経路を通り、クラッシュはそれを飛ばします。したがって一方の結果は他方に当てはまらず、メニュー項目を使った試験はクライアントが落ちたときの挙動についての主張を支えられません。

同じように、クラッシュは承認された一時停止について何も語りません。この三つの問いを、試験計画とその後書き留めるすべての中で分けておいてください。終了経路は、正常終了がクラッシュの残すルールを削除できる理由も説明します。同じボタン、違うコード、違う証拠です。

本当に必要な利用不可の状態を選ぶ

トンネルが落ちている間は常に通信をブロックする必要があるなら、気にしている特定の操作の間に、既知の宛先への無害な通信を使ってその要件を確かめてください。端末全体への適用は名前が示すより狭いことが多いため、アプリの除外とローカルネットワークの例外も含めてください。古い状態が現れるのはたいてい再起動後なので、そのときに何が起きるかを確認してください。

目的が通常の直接アクセスなら、プロセスを殺したりファイアウォール全体を無効にしたりせず、ドキュメント化された操作を使ってください。中断された終了が残す古いルールは、意図的なロックダウンとは別の問題であり、別の復旧が必要です。

どのコンポーネントが止まったのか（トンネルか、見えているアプリケーションか、ポリシーを適用する層か）を書き留めてください。その一文が、これらの操作が生む混乱のほとんどを防ぎます。