VPN は接続済みなのに既定ルートが死んでいる
Wi-Fi から Ethernet への切り替えで、ルートとリゾルバーが古いトンネルに残ることがある。二つの状態を別々に読み、間違っているほうを直す。
クライアントは接続済みと報告し、トレイのアイコンも正常に見えるのに、何も読み込まれない。Wi-Fi からケーブルに切り替えた直後、あるいはディストリビューションのアップグレードが終わった直後に始まった。壊れたのはプロファイルではなく、以前のベース接続のために作られた状態のほうだ。カーネルにはまだ、誰も所有していないトンネルデバイスを指す既定ルートが残っているか、リゾルバーが消えたリンク上のサーバーを依然として列挙している。どちらの故障も死んだネットワークに見えるが、どちらもその場で修理できる。
古い部品は、あなたが気づく前からすでに間違っていた。ケーブルを抜いたことで見えるようになっただけだ。
カーネルにパケットの行き先を尋ねる
ルートの一覧は、システムが知っているすべてを列挙し、もう適用されない項目まで含むので読みにくい。ルート検索は、問う価値のある唯一の問いに答える。いまこのパケットを運ぶのはどのデバイスか。答えがトンネルデバイスを示すなら、その背後に生きたクライアントプロセスがなくてもカーネルはそれを使い、パケットは誰も保守していないインターフェースに落ちる。答えが Ethernet アダプターを示すのにクライアントが接続済みだと言い張るなら、トンネルは存在するが選択を失ったのであり、無線から有線への切り替えではよくある結果だ。
公開アドレス用に一度、社内アドレス用にもう一度、検索を二回実行する。分割トンネルのポリシーは一方を正直に通し、もう一方を落とすことがあるからだ。
ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40リゾルバーも死んだリンクを保持する
systemd-resolved を使うホストでは、DNS サーバーはリンクに属し、単一のグローバルリストには属さない。落ちた VPN リンクはしばらく自分のサーバーとともに登録されたままで、その間すべての検索は決して答えないアドレスを待つ。その遅延は死んだネットワークのように感じられ、ルートは正常なのに人をルートへ向かわせる。
resolvectl status
resolvectl query intranet.example.comリンクごとのブロックを読み、問題のドメインを所有しているのがどのリンクかを特定する。起動していても社内ドメインの所有者ではないトンネルは、社内の名前を公開リゾルバーへ転送し、症状はルーティング障害と区別できない。
直すべきは登録であって、 /etc/resolv.confではない。現在の Ubuntu と Fedora のインストールでは、そのパスはリゾルバーの実行時状態へのシンボリックリンクなので、編集は無視されるか、次のネットワークイベントで上書きされる。
VPN は決して自分では起動しない
NetworkManager はベース接続の上に VPN を立ち上げ、どれに従うべきかをベース側の connection.secondaries から学ぶ。 接続設定のリファレンス は、VPN プロファイルでは自動接続が実装されていないと明言している。これがこの種の故障の仕組みのすべてだ。ベースを変えれば、VPN は手動で再度ペアリングするか再有効化しなければならない。
nmcli device status
nmcli connection show --active
nmcli connection up office-vpn有効な一覧に VPN なしのベースが表示されるなら、トンネルはまったく有効ではなく、ルートは古いまま残ったのではなく一度も入っていない。有効化がソース接続が存在しないと訴えるなら、ペアリングしていたベースが消えているので、まずベースかペアリングを直し、VPN を再試行するのはやめる。
アップグレードは通知なしに設定を落とすことがある
ディストリビューションをアップグレードするとクライアントと、しばしばその NetworkManager プラグインが置き換わるが、保存済みのプロファイルは書かれたときのプロパティ名をそのまま保つ。新しいプラグインが認識しなくなったものは黙って飛ばされる。プロファイルは今も有効になり、デバイスも今も現れるが、以前は一緒に来ていたルートはもう来ない。
手書きのフックも動く。古い順序の予測できる時点でルートを入れていたスクリプトは、いまやインターフェースが存在する前に走るか、クライアントがすでにタイムアウトした後に走るかもしれない。
動いているプロファイルを、覚えている挙動ではなく、実際に持っているプラグインと比べる。キーがドキュメントから消えているなら、古いプロパティを復元するのではなく、ディスパッチャースクリプトかサポートされた代替へ作業を移す。
三つの状態、三つの異なる修理
何かに触れる前に自分がどの状態かを決める。再起動は証拠を壊し、次のネットワーク変更で障害が戻るからだ。
| What the lookup shows | What it means | Repair |
|---|---|---|
| A default route via a device that exists but is unused | Leftover route from an earlier activation | Remove the stale entry, or bounce the profile that installed it |
| A tunnel device with no client process | The client skipped its cleanup | Fix the disconnect path, then clear the leftover device state |
| No tunnel device and no active profile | Missing base connection or broken pairing | Bring up the base, then pair the VPN with it again |
公開アドレスの検索を一回、社内アドレスの検索を一回、名前の問い合わせを一回で終える。アドレスは動くのに名前が動かないなら、残る障害はリゾルバー内のドメインスコープであり、ルートテーブルは最初から問題ではなかった。