OpenVPNクライアントが一回のタイムアウトで停止したままになる理由

月曜の朝：金曜に立ち上がったトンネルは消え、インターフェースはまだ一覧にあり、ジャーナルには誰かが気づいたという記述はありません。ホストはオンラインで、ダッシュボードは緑のままで、週末に送ったものはすべて物理インターフェースから出ていきました。ここでは、クライアントのプロセスが一時的な障害を生き延びるかどうかと、その上にある何かがプロセスの終了後に再起動するかどうかという、独立した二つの判断が欠けています。片方だけ直すと、もう片方の隙間は開いたままです。

監視の主張ではなく、ユニットが実際に行ったことから始めます。systemctl status openvpn-client@officeとjournalctl -u openvpn-client@office -n 50が終了理由と、クライアントが去る前に書いた最後の行を示します。

誰かが気づく前にプロセスは終了していた

エラーなく消えるクライアントは、たいてい意図的に終了しています。その動作を決めるのはサービス管理ではなくプロファイルです：ping-exitは相手が応答をやめた時点でプロセスを終了し、ping-restartはプロセスを保持してその内部で再接続します。セッション上限や無操作タイマーも、外から見ればトンネルも警報もない同じ姿になります。

二つのping指示は同じプロファイルに共存できないため、片方を選んで記録します。サーバーも確認してください：サーバー自身のping-exitはクライアントの要求に関係なくセッションを閉じ、その判断を記録するのはサーバーログだけです。

ping-exitとping-restartのどちらを選ぶか

自分で回復すべきノートPCや遠隔拠点にはping-restartを選び、死んだトンネルがプロセスを止めて何か別のものに対応させたい場合にはping-exitを残します。数字よりも関係が重要です：ping 10とping-restart 60の組み合わせは、検査前に十秒、再起動前に六十秒の沈黙を意味し、損失のあるモバイル回線では攻撃的、有線では妥当です。理由は行の隣に書いておかないと、次の読者は既定値が意図的だったと受け取ります。

次に、終了したのが本当にプロセスなのかを確認します。トンネルが死んでいるのにアクティブだと報告するユニットは別の障害で、下で扱います。

ユニットを本当に再起動する監視

systemdホストでは、最小の恒久的な変更は、Restart=on-failureとRestartSec=10を/etc/systemd/system/[email protected]/restart.confに置く一つのdrop-inファイルです。drop-inはsystemdが自身の定義を再読み込みしたときにだけ読まれるので、その後にsystemctl daemon-reloadを実行します。値が反映されたと決めつけず、systemctl show -p Restart -p ExecMainStatus openvpn-client@officeで検証してください。ファイル名のインスタンスはユニットが実際に読み込むプロファイルでなければならないため、office用に書いたファイルはopenvpn-client@homeには何の効果もありません。

on-failureは一つのケースを無視します：ステータスがゼロの正常終了です。一部の解体経路はそう終わるので、マニュアルページの文言を信じず、記録されたステータスを読んでください。クライアントがゼロで諦めるならRestart=alwaysが必要で、その代償は、本当に壊れたプロファイルが起動レート制限にかかってジャーナルが埋まるまで何度も戻ってくることです。

Restart=alwaysは意図的な停止の後にも発動します。メンテナンスにはsystemctl stopを使い、作業中にユニットを止めたままにする必要があるならマスクしてください。

トンネルが落ちている間に漏えいを捕まえる

監視はトンネルを戻しますが、トンネルがない間に通信が外へ出るのを止めはしません。persist-tunは再接続をまたいでデバイスとそのルートを保持し、便利である一方で窓を開けます。デバイスは残り、ルートは依然としてそこを指し、パケットは保護も通知もなく外へ流れます。これはポリシーの選択であり、中立な既定値ではありません。

ホストが保護されていないパケットを一切出してはならない場合、それを保証できるのはファイアウォールだけです。トンネルインターフェースとVPNサーバーのアドレスを許可し、それ以外をすべて破棄する出力ルールは、クライアントが死んだ後も効き続け、クライアント自身の設定には、クライアントが運んでいない通信をフィルターできるものは何もありません。

クライアントを意図的に止めて試します。systemctl stop openvpn-client@officeを実行し、次にcurl -m 5 https://example.comを実行すると、物理リンク上では成功せず失敗するはずです。成功したなら、ファイアウォールのルールが欠けているか緩すぎます。

再接続し、トンネルが再び通信を運ぶことを確認してから、監視にチェックを追加します。cronからip addrをtunデバイスに対してポーリングするのは最もよく失敗する監視です：persist-tunがあるとデバイスはセッションより長く残り、何も運んでいないのに検査は健全だと報告するからです。