VPNが切断されたのにインターネットが遮断されたまま：スイッチか古いルールか？

トンネルが閉じ、ブラウザーが止まり、同じWi-Fi上の他の端末はすべて動いているので、ルーターは除外できる。このパターンには、遮断を命じられたキルスイッチ、削除されたクライアントが残した状態、復元されなかったリゾルバーやルートという三つの候補がある。ブラウザーの窓から見るとどれも同じに見えるが、必要な修理は違う。ネットワークのリセットを実行する前に、どれに当たるのかを決めよう。

二つのまったく異なる遮断されたインターネット

意図的な遮断は機能で、トンネルが有効でない間はクライアントが通信を捨て、保護された経路の外に何も漏らさない。偶発的な遮断は、クライアントの終了後も残ったルールや端末、リゾルバーの設定だ。一方は接続するかポリシーを意図的に無効にして直し、もう一方は残されたものを片付けて直す。

違いはブラウザーではなくエラーに現れる。意図的な遮断は通常、即座の拒否か静かな停止を生むが、残ったリゾルバーは、リテラルアドレスへのpingが通るときでも続く名前解決の失敗を生む。どちらも壊れたWi-Fi接続とは違い、それは他の端末にも影響する。その違いに沿って、まずリテラルアドレス、次に名前という順に確認を並べよう。

クライアントが切断時に約束したこと

多くの製品が一時停止と完全停止を分けているため、切断の意味はクライアント自身の設定で読むべきだ。一時停止は設計上遮断をそのまま残し、停止はそれを外すことがある。一部のモバイルプラットフォームは、VPNが接続されていないときは常に通信を遮断する常時オンのルールとして同じ考えを表す。

組織が保護を求める場合、修理は遮断を迂回することではなく正しいプロファイルに再接続することであり、サーバー名がまだ解決でき、展開が文書化した例外を通じてエンドポイントに到達できることを確認すべきだ。失敗した再接続は持続的な遮断とまったく同じに見えるからだ。

中断された削除が残した古い状態

中断されたアンインストールや、トンネルが有効なまま削除されたパッケージは、ファイアウォールのチェーン、ルーティングルール、リゾルバーのエントリ、仮想アダプターを残すことがある。プロセスは消えたが、影響は消えていない。

アプリケーションがサポートするクリーンアップと修復の手順から始め、削除する前に、どのコンポーネントが残った各オブジェクトをインストールしたかを特定しよう。ホストのファイアウォールを切ると閲覧は戻るが、無関係な保護も同時に失われる。グローバルなネットワークリセットは、原因を名指しせずに機能しているオフィスやWi-Fiの設定を捨ててしまうので、もっと悪い。

二つのクライアントがインストールされている場合は、どちらがポリシーを所有するかを決めよう。所有者が二つあると、遮断は両方を削除しても生き残る。

閲覧だけでなく、切断された状態を検証する

閲覧が再び動くことは弱い受け入れテストだ。必要なポリシーが無傷で、他に何も静かに弱められていないことを検証しよう。

ip rule show
ip route show table all | grep -v '^default'
resolvectl status | head -n 20
sudo nft list ruleset | grep -A 6 'chain output'

ルーティングルール、リゾルバー、ファイアウォールのポリシーを、きれいに切断されたマシンの姿と比べよう。その後、通常のワークフローで再接続と切断を行い、読み取りを繰り返して、期待される状態を記憶ではなく記録に残す。

そのビフォーアフターの組をチケットに残そう。遮断されたブラウザーを見る次の人は、どのクライアントが最良かというもう一つの意見より、それを必要とする。