スリープ後にVPNが死ぬ：トンネル消失か、古いアプリか

蓋を開けるとワイヤレスのアイコンが戻り、VPNは接続中と表示されたままです。最初の社内ページはタイムアウトまで固まり、新しいタブでも同じことが起きます。この絵を作り出す原因は三つあり、それぞれ別の対処が必要です。スリープを生き延びなかったトンネル、誰も再有効化を求めなかったプロファイル、数時間前に死んだセッションをまだ抱えているアプリです。三つを比べるほうが、何かを再インストールするより速いのです。

復帰後に壊れうる三つのもの

第一の候補はトンネルそのものです。ピアとの関連が消えてもインターフェースはアドレスを保ったまま残ることがあり、だからインジケーターの光は経路が生きている証拠にはなりません。スリープより古いハンドシェイクがその兆候で、見るにはコマンド一つで足ります。

第二は有効化です。多くのクライアントは自分で再接続しますが、そうしないものもあり、戻るよう誰も求めていないプロファイルは設定済みの顔をしてそこに居座ります。この失敗は設計上、静かなままです。何もエラーを出さないからです。

第三はアプリです。ブラウザのタブ、SSHセッション、データベース接続は、下の転送が死んでいてもファイルディスクリプタとしてネットワークの変化を生き延びられます。すると新しいセッションは完璧に動き、トンネルはずっと正常だったことが分かります。

何かを変える前に三つを比べてください。対処は重なりません。再起動を求められていないクライアントを再起動すると、必要な証拠を捨てることになります。設定に触る前に、症状がどの候補に当てはまるかを書き留めてください。その一文がたいてい残りの調査を決めます。

第一に：トンネルは戻ったか

クライアント自身の状態表示ではなく、インターフェースとピアの状態を見てください。アドレスがあり最近のハンドシェイクがないインターフェースは、名前だけのトンネルです。

ip -brief addr show
wg show
ip route show table all | head -20

インターフェースが完全に消えていればトンネルは生き延びておらず、誰が戻すべきだったかという問いになります。あってもハンドシェイクが古ければピアとの関連を再確立する必要があり、クライアントは通信が来て発火するのを待っているのかもしれません。

ルートとDNSの設定も確認してください。トンネルはルートなしで戻ることがあり、インターフェースは上がっているのに社内名がまだ間違ったサーバーで解決されるという紛らわしい状態になります。

第二に：戻るよう求めたものはあるか

ここで比較が効いてきます。OpenVPNのプラグインプロファイルとネイティブなWireGuard接続はNetworkManagerで扱いが異なり、接続設定のリファレンスはconnection.autoconnectがVPNプロファイルを有効化しないと明言しています。接続と一緒にVPNを立ち上げる仕組みはconnection.secondariesです。

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

手動で再接続すると毎回直るなら、それは壊れたトンネルではなく有効化の欠落の印です。ログにはたいていインターフェースが落ちて、何も戻さない様子が残ります。

すぐにスリープフックを足したい衝動を抑えてください。ネットワークが回復する前に動くフックは、助けようとしている当のプロセスと競合し、再現できる問題を時々起きる問題に変えてしまいます。

第三に：アプリが古い状態を抱えていないか

VPNに触る前に、同じ宛先へまったく新しいセッションを開いてください。新しいセッションが動き古いものが動かないなら、トンネルは正常でアプリが死んだ接続を抱えています。

これは三つの確認のうち最も安く、最も飛ばされがちです。失敗しているウィンドウが画面の目の前にあるからです。閉じて開き直し、問題が残るかを見てください。新しいセッションが動くなら、トンネルの調査は完全にやめてください。それも失敗するなら、アプリは原因ではなく症状です。

アプリによってはタイムアウト後に自力で回復し、数分後に症状がひとりでに直ったように見えることがあります。その挙動はトンネルではなくアプリを指しており、別に記録する価値があります。勝手に直ったと報告する同僚はこのパターンを語っているのであって、幸運ではありません。

比較を再現できる形にする

変数を小さく保ってください。ひとつのアクセス網、ひとつのスリープ時間、毎回同じ最初のリクエストです。そして二つの結果を記録します。手動の再接続で直るか、もう一度スリープすると失敗が戻るかです。

最後の観察こそが、三つの候補を最も確実に切り分けます。失敗した古いセッションの後に新しいセッションが動くなら、それはトンネルの問題ではなく、クライアントを再インストールしても変わりません。

WireGuardの常時keepaliveは、この絵ではNATマッピングのkeepaliveとしてのみ意味を持ちます。マッピングを開いたままにするためにパケットを送りますが、マシンがスリープするのを止められず、プロセスが停止している間は送り続けられません。

チケットには見つけたことを書いてください。三つのどれが壊れていたか、何が直したか、どう再現したかです。月曜日に蓋を開ける次の人があなたに感謝し、答えをゼロから見つけ直さずに済みます。