VPN は接続済みと言うのに何も流れない：見るべき二つの場所

トンネルは接続済みだと報告できるのに、そこには何も届かない。一つは経路テーブルで、誰も持っていないデバイスへパケットを送り続けていることがあり、もう一つはリゾルバーで、消えたリンク上のサーバーをまだ並べていることがある。ネットワークの変更はプロファイルを壊したのではなく、前の接続に属していた状態を孤児にした。どちらを見ているかで直し方が変わる。

まずカーネルに、どのデバイスを使うのかを聞く

経路の一覧は何が存在するかを示し、経路の問い合わせは何が起きるかを示す。公開アドレスについて問い合わせ、答えの中のデバイス名を読む。この一つのフィールドが、パケットが役に立つ場所へ出るかどうかを決める。答えがトンネルデバイスを名指ししたら、そのインターフェースの後ろでクライアントのプロセスがもう動いていなくても、カーネルはパケットをそこへ渡し、物理アダプターを名指しするのにクライアントが接続済みだと言っているなら、トンネルは上がっているが選ばれた経路ではない。

二つ目の場合は、ケーブルが無線に取って代わった後によく起こり、壊れた VPN のように見える。

ip route show default
ip route get 203.0.113.9

次に既定の経路の項目を読む。前の基底の接続が加えた経路は、リンクの変更より長く生き残って新しい経路の前に立つことがあり、落ちているデバイスを通る既定の経路は、カーネルがそれでも優先するため、既定の経路がないより悪い。各項目の横のメトリックに注目すると、この順序はインターフェース名より速く優先度を説明する。

次にリゾルバーをリンクごとに読む

名前解決は自分の状態と自分の古さを持っている。リンクごとに DNS サーバーを並べるリゾルバーは、落ちているが登録は残っているトンネルのリンクのサーバーを保持し、問い合わせのたびに答えないサーバーを待つ。症状は、経路テーブルが完璧に見えるのにネットワークが死んだように感じることだ。

ファイルではなくリンクごとの状態を見る。多くのディストリビューションではそのファイルはリゾルバーへのシンボリックリンクで、編集しても何も起きないか、すぐ上書きされる。どのリンクがどのサーバーとどの検索ドメインを持つのかを見て、そのトンネルのリンクがまだ登録されているべきかを問い、べきでないなら、生成された状態を手で直すのではなく、それを持つ接続を無効にする。経路の問い合わせがパケットを別へ送るのに名前が解決するなら、それは三つ目の別の不具合だ。

resolvectl status
resolvectl query app.internal.example

アドレスが解決して接続が失敗するなら、リゾルバーは正常で経路が問題だ。アドレスがまったく解決しないなら、ここが調べ始める場所だ。

古い経路が変更を生き延びる仕組み

クライアントはネットワークを一人で所有しているわけではない。NetworkManager のホストでは VPN のプロファイルが基底の接続の上で有効になり、接続の設定はその基底に、後を追うべき VPN を名指しさせる。基底が別のプロファイルを好むようになって変わると、トンネルは新しい基底へ移るか、基底を持たないままになる。

VPN のプロファイルは自分で上がってこないので、この組み合わせはプロファイル自身の自動接続の好みよりずっと重要だ。

有効な一覧を読み、トンネルに触れる前にどの基底が上がっているかを記す。基底が一覧にあり、トンネルがないなら、経路が古いのではなく欠けていて、直し方は有効化だ。トンネルを有効にすると元の接続がないと文句を言うなら、組になっていた基底が消えているので、トンネルを再試行するのではなく、先にその基底を上げるか組み合わせを直す。親のないプロファイルを再試行すると毎回同じエラーになり、これは厄介事ではなく有用な信号だ。

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

古い状態と親の不在を区別する

三つの状態でほぼすべての報告を説明でき、それぞれ直し方が違う。まだ存在するがトンネルを運ばなくなったデバイスを通る既定の経路は古い状態で、項目を消すか、責任のあるプロファイルを再起動して片づける。クライアントのプロセスが消えたトンネルのデバイスは後片付けの失敗なので、注目すべきは切断の経路で、経路テーブルではない。トンネルのデバイスがまったくないなら、親か組み合わせが欠けており、経路テーブルは最初から関与していない。

再起動は三つのうちどれだったかを隠してしまい、だからこそ直ったように感じる。

直した後で、カーネルに公開アドレスと内部アドレスを一つずつ尋ね、次に内部の名前を問い合わせる。アドレスが通り名前が通らないなら、見つけたのは経路ではなくリゾルバーのドメイン範囲の問題だ。見つけた状態を書き留めておくとよい、次のネットワークの変更が、手を付けなかったほうをまた再現するからだ。