画面が暗くなるとVPNが切れる：ロック、消灯、それともスリープ？
セッションのロック、画面の消灯、マシンのスリープは三つの別の出来事です。VPNのキープアライブを疑う前に、journalctlで突き合わせてください。
画面が暗くなったときにVPNが死んだと言う人がいるとき、最初に役立つ問いは、三つの出来事のうち実際にどれが起きたのか、つまりセッションがロックされたのか、パネルが消灯したのか、それともマシン全体がスリープしたのかということです。これらは別々のタイマーで動く別々の仕組みであり、プロセスのスケジュールを完全に止められるのはそのうち一つだけです。以下の確認を順番に進め、問いに答える最初の確認で止めてください。それ以降の確認は別のことに答えています。
確認その一：ロックと消灯とスリープを切り分ける
ロックはセッションを使える人を変えるだけで、コンポジタは描画を続け、ネットワークスタックは動き続け、VPNクライアントは何も気づきません。画面の消灯はアイドル時間の後にパネルを切るだけで、マシンは完全に起きています。スリープはCPUを止めるので、ユーザー空間のプロセスはまったくスケジュールされず、間隔をどれほど短くしてもキープアライブは発火できません。
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
この表があるからこそ「画面が暗くなった」は診断ではありません。五分で消灯し三十分でスリープするよう設定したデスクトップは、六分の時点で真っ暗な画面を見せますが、トンネルは完全に健全です。三十分の時点の故障は別の出来事で別の対処が必要であり、部屋の反対側から見るとどちらも同じに見えます。
確認その二：電源とネットワークの出来事を一つの時間軸に載せる
起動全体ではなく区切った時間枠でジャーナルを読み、ログインマネージャと接続の持ち主の両方を含めてください：
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list最初のコマンドはスリープ要求、復帰、その後に続いたネットワーク遷移を示します。二つ目は現在どのプロセスがインヒビタロックを保持しているかを示し、何かが意図的にスリープを止めているかどうか、それがどのプログラムかを教えてくれます。接続の持ち主がNetworkManagerでない場合はユニット名を調整し、他のユーザーのユニットやシステムジャーナルを読めるかはローカルのポリシー次第だと覚えておいてください。
行が欠けていることは否定的な結果ではありません。選んだユニットのジャーナルがあなたのアカウントから見えないなら、スリープの記録がないことは何も証明せず、空のフィルタから「一度も眠っていない」と結論するのは、人々が一週間キープアライブを調整して過ごす道です。
確認その三：スリープしたなら、それが意図したものか判断する
スリープの遷移が時間軸に載った時点で、問いは「なぜVPNが壊れたか」から「そもそもマシンは眠るべきだったか」に変わります。ノートPCでは答えはしばしば「はい」であり、トンネルの切断は想定内の挙動で、復帰時にクライアントが回復すべきものです。到達可能であり続けるべきワークステーションでは、変えるべきはスリープのポリシーです。この二つのどちらのマシンを見ているのかを決めるには一つの問いが要り、それはジャーナルが代わりに答えてくれる問いではありません。
ログイン中のセッションに属する設定から変えるか、要件がマシン全体に及ぶなら管理者が支援する仕組みで変えてください。別のアカウントでログインしたままディスプレイマネージャの設定を編集するのは同じ操作ではなく、次のセッションが始まるまで効いたように見えるだけです。電源管理を完全に無効にするのは、バッテリー寿命を犠牲にして本来のポリシーの問いを隠す、大雑把な最初の反応です。
確認その四：起きたままなら、ネットワークとクライアントを見る
トンネルを失ったまま起きているマシンには、アクセスネットワークが落ちた、VPNクライアントが停止または再起動した、あるいはサーバ側が関連を失効させたのにクライアントは接続していると信じ続けていた、という三つの筋書きのどれかがあります。下位のリンクの出来事のタイムスタンプをトンネルの出来事と比べ、どちらが先だったかを正確にしてください。
次に、元のセッションとは別に復旧経路を試してください。復旧したトンネル経由の新しい要求は成功しても、切断前に開いた長時間のアプリケーションセッションは、アプリケーションが古いソケットやキャッシュされたアドレスを保持しているために壊れたままになることがあります。それはアプリケーションの問題であり、トンネルが戻らなかった証拠ではありません。
役に立つ報告に含めるもの
タイムスタンプと持ち主を添えて、セッションがいつロックされたか、画面がいつ暗くなったか、スリープ要求が記録されたか、リンクがいつ落ちて戻ったか、トンネルがいつ状態を変えたか、アプリケーションが実際に何をしたかを順序として書いてください。どの項目にも持ち主がいるので、Linuxについての漠然とした不満になる代わりに正しい人へ渡せます。
これらの行のどれかが欠けているなら、それは次に測るべきことであり、次に変えるべきことではありません。隙間のある時間軸は、勘で行った設定変更より多くを語ります。