VPNアプリを切るとインターネットが止まる：確認すべき4つの層

無料のVPNクライアントやブラウザ拡張を一週間試してから切ると、インターネットが止まってしまう。Wi-Fiのアイコンは接続を示したままで、同じルーターにつながる他の端末は問題なく動いており、閲覧を取り戻せるのはアプリを再有効化するかアンインストールするときだけだ。このパターンは暗号化が依存関係を生んだのではない。アプリがトンネルの管理下にないどこかに書き込んだ設定によるものだ。

クライアントはトンネルが管理しない設定を書き換える

WindowsやmacOSのプライバシー系クライアントは、たいてい三か所を同時に触る。インターネットオプションと同じ欄であるシステムのHTTPプロキシを設定する。パケットを取得するために、多くの場合TAPドライバーである仮想アダプターを導入する。そしてリゾルバーの一覧を書き換える。しかし切断を押したときに消えるのはトンネルだけだ。

ブラウザ拡張はもっと範囲が狭い。通常は自分自身のプロファイルか、そのブラウザだけが従うプロキシを変更する。だから一つのブラウザだけが失敗し、コマンドラインツールは動き続けることがある。逆も同じで、拡張には他の層に触れる権限がなかったのだ。どの層を編集したかが、どのツールが壊れるかを決める。

いずれにせよ、その古い判断は、取り消す理由を持たないソフトウェアによって行われた。トンネルは目に見える部分であり、きれいに終了できる唯一の部分でもあった。それ以外はプロセスより長生きする保存場所の設定なので、アプリを削除することが三つを一度に戻す唯一の手順になる。何かを再インストールする前にこれらの保存場所を読むことが、症状を診断に変える。

三つの残骸、三つの異なる故障

一つ目の残骸は、何も指していないプロキシだ。LANプロキシのチェックが入ったままだったり、もうプロセスが待ち受けていないlocalhostのポートを指す構成スクリプトのURLが残っていたりする。ブラウザはすべての要求をその死んだポートへ転送し、タイムアウトがまるでネットワークが死んだように見えるまで待ち続ける。二つ目は、既定ルートをまだ握っているアダプターだ。TAP-Windowsデバイスやベンダーのルーティングドライバーは、アンインストール後も本物のインターフェースとして残る。与えられたルートを保持し続け、通信は存在しないトンネルへ消えていく。どちらの残骸も自分から名乗り出ることはなく、どちらも停止そっくりに見える。

三つ目はDNSで、これは他の二つより早く失敗する。リゾルバーの一覧にトンネル経由でしか届かないサーバーしかなければ、ページを一つ要求する前にすべての名前解決がタイムアウトする。そのためブラウザは、死んだプロキシではなく到達できないサイトとして報告する。どれに当たっても、ネットワーク的な意味での障害ではない。どれも誰も取り消さなかった残骸であり、それぞれ別の場所で直す。

四つの層を上から下へたどる

アプリケーションに最も近い層から始めて下へ進む。層はその可視性の順に失敗するからだ。テストごとに一層だけ変更し、そのたびに再テストする。すべてを一度にリセットすると閲覧はたいてい戻るが、どの残骸が原因だったかを言えなくなり、次のインストールで同じ謎が再現される。順序はプロキシ、アダプター、ルート、リゾルバーだ。

Windowsでは、どの確認もOSに同梱のコマンド一つで済むので、何もインストールする必要はない。順番に実行し、出力をまとめておく。四つの答えは並べて初めて意味を持つからだ。プロキシ、アダプター、IPv4ルート、リゾルバー一覧を、この順に報告する：

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

LinuxとmacOSにはそれぞれのコマンドが必要で、互換性はない。Linuxではルートはip routeから、リゾルバーはsystemd-resolvedが管理している場合はresolvectl statusから得て、それがなければcat /etc/resolv.confに頼る。macOSではルートはnetstat -rnから、リゾルバーはscutil --dnsから、システムプロキシはscutil --proxyから得る。macOSの読者がip routeを実行すればcommand not foundとなり、そこでの/etc/resolv.confは権威ある設定ではなく生成されたスタブだ。層を確認する前にプラットフォームを確認しないと、最初のコマンドが発見そのものになってしまう。

各層について一つの問いを立てる。アプリを閉じている間も、その値は実在する何かを指しているか。死んだポートのプロキシ、トンネルのないアダプター、ダウンしたインターフェース経由の既定ルート、トンネル内のリゾルバーは、どれも答えは否だ。一つの否で症状を説明できるからこそ、テストごとに一変更が重要になる。

プロキシはトンネルではない

プロキシは要求を受け取り、どこか別の場所で取得し、応答を返す。つまり宛先を知っており、サイト自身が暗号化していないものはすべて見える。他のプロトコルを運ぶことはない。宛先がすでにTLSを使っていない限り、経路を保護しない。そしてインストールしたものによって、あなたの関与なしに変更されうる。

この区別は、問うべき質問を変える。プロキシが残っているなら、トンネルが上がっているかではなく、どのプログラムがまだブラウザを誘導しているかを見つけるべきだ。トンネルは完全に健全で、障害とはまったく無関係かもしれない。

そのようなクライアントが実際に何をしたかを知りたいなら、ダッシュボードを読むのではなく観察する。Process Monitorは触れたレジストリキーとファイルを記録し、パケットキャプチャは通信がどこへ行ったかを明らかにする。どちらも普通のツールで、どちらもどんな状態表示よりも残骸の問いに答えてくれる。どちらもアプリが動き続けている必要はない。

証拠ではなくコンポーネントを取り除く

持続する修正は、設定を書いたものを取り除くことだ。アプリをアンインストールし、追加された仮想アダプターを削除し、プロキシとリゾルバー一覧を消し、再起動してアプリをインストールしないままテストする。そこで閲覧ができれば、回避策ではなく原因を見つけたことになる。どの層が古かったかを書き留めておく。同じベンダーは同じ間違いを二度繰り返す傾向がある。

次のクライアントをインストールした後に症状が戻ったら、サービスが何かを壊したと決める前に、もう一度四つの層をたどる。証拠はたいてい、四つの場所のどれかにまだある。二つ目のアプリが五つ目の層を作るのではなく、四つのうちの一つを編集するのだ。

再インストールはプロキシを戻すが、古いアダプターは戻さず、リゾルバーを二つ一覧に残すことがある。この非対称性こそ、すべてをリセットするボタンよりアンインストールしてテストする方が勝る理由だ。次に接続が切れたとき比較できる基準にもなる。