クライアントは消えたのに、マシンはまだどこにも到達できません。だからといってファイアウォールを平らにして最初からやり直すのはやめてください。ブロック状態は同じマシン上の三つの異なる所有者から来ることがあり、それぞれに独自の削除経路があります。すべてを一度に流し込むと、消したかった対象がまだ必要な保護と一緒に消え、どの所有者が問題を起こしたかの証拠も破壊されます。五つの確認を順番に行えば、それが防げます。

確認1:何がまだ残っていて、何のためのものか

三つの痕跡を別々に探します:まだ存在する仮想アダプター、まだブロックしているファイアウォールのフィルターまたはルール、そしてもう存在しないトンネルをまだ指しているルートまたはポリシールールです。それらがあること自体は何も証明しません——なぜなら意図的なキルスイッチは外から見ると放置されたものとまったく同じに見えるからです。

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object Action -eq 'Block'
ip route show
ip -4 rule show

接続が止まった時刻と、通常のクライアントがまだトンネルを起動できるかを書き留めます。クライアントがトンネルを復元でき、トラフィックが戻るなら、ブロックは役割を果たしており、問題は残ったルールではなくクライアントの状態にあります。

確認2:どの所有者がそれを制御しているか

各痕跡には所有者があります。仮想アダプターはVPNクライアントまたはそのドライバーのものです。フィルターはクライアント、プラットフォーム自身のファイアウォール、または管理されたセキュリティ製品のものである可能性があります。ルートは接続時にクライアントがインストールし、そのまま残したのかもしれません。

管理された機器では、何かに触れる前にデバイスポリシーを確認します。ポリシーで強制されるフィルターは次のチェックインで復元されるので、ローカルでの削除は一時間とコンプライアンス報告を買うだけです。その話し合いは管理者のものであり、ファイアウォールのUIのものではありません。

確認3:それを説明する最も狭いものを削除する

ベンダーがサポートする経路から始めます:修復インストールや適切なアンインストールは、手動削除では見落とすフィルターを含め、生成された状態を正しく片付けることがよくあります。インストールされているバージョンの回復手順を読んでください——順序が重要で、失敗した削除の後のアンインストールは動作が異なります。

手動での検査が本当に必要な場合は、何かを変更する前にルール名、インターフェース、宣言された目的を記録し、その対象を名前で削除します。一つのクライアントを狙ってすべてのネットワークアダプターを削除したり、ルールセット全体を流し込んだりするのは、サポート案件が再構築になる道です。

確認4:DNSとルートはアダプターより長く残る

解決状態はトンネルより長く残ることがあります。もう存在しないトンネル内のアドレスをまだ指しているリゾルバーは、ファイアウォールのドロップとまったく同じに見えるタイムアウトを生み、通常の結論は間違っています。

resolvectl status
ip route get 1.1.1.1
nslookup example.com

アドレスが解決でき、IPによる生の接続が機能するなら、残る問題はDNSであり、フィルタリングではありません。どちらも失敗するなら、ルートとフィルターを手に最初の確認に戻ります。

確認5:両方の経路を再テストし、診断を元に戻す

まず通常の接続を確認し、次に残っている各VPNプロファイルをそれぞれのコントロールで確認します:接続し、使用し、切断し、ホストが素の接続に戻ったことを確かめます。その往復こそが、放置されたブロックが単に回避されたのではなく消えたことを証明するテストです。

最後に、途中で行った診断上の変更を元に戻します。成功したクリーンアップは放置された依存関係を一つ削除しますが、ホストの一般的な保護を削除するものではなく、恒久的に緩められたファイアウォールを残すべきでもありません。どの所有者がブロックを保持していたかを記録してください——次のアンインストールでも同じ三つの候補が生まれます。

関連記事