OpenVPN を毎日再起動すべきか。選ぶべきは時計ではなく障害

毎日 04:10 に OpenVPN を再起動する cron ジョブを引き継ぎ、それで一年間安定してきたとします。しかし同じジョブは、健全なトンネルを決まった時刻に切断し、実際に昼休みに起きる障害には何もしていません。カレンダーによる再起動は保守の判断です。復旧は、特定のトリガーを持つ別の設計です。

三つの障害の形には、三つの異なる所有者が必要です。まず障害を選べば、仕組みは後からついてきます。

三つの障害、三つの所有者

ピアが消えてもトンネルは起動したままになり得ます。プロセスは動き、インターフェースは存在し、その中を有益なものは通りません。ピアが正常でもプロセスが死んでいることがあり、その場合はそれを起動したものだけが戻せます。トンネルの背後にあるアプリケーションは、トンネルもピアも健全なまま壊れていることがあり、そのときにクライアントを再起動すると原因に触れないまま障害を広げます。この三つを切り分けることが判断のすべてです。

それぞれに独自の信号と所有者があります。生存性は VPN プロトコルに、プロセスのライフサイクルはサービス管理に、アプリケーションの健全性は狭い権限を持つ監視に属します。

生存性のオプションにできること、できないこと

keepalive は ping と ping-restart の組に展開される補助であり、リンクオプションのリファレンス が説明する通り、それが生み出すタイムアウトはサーバーとクライアントで同一ではありません。サーバーが送る値はクライアントがローカルに設定した値を上書きすることもあり、ローカルファイルで正しく見えるタイムアウトが実際に有効なものとは限りません。

そのため、失われたピアには適した道具で、死んだプロセスには不適切な道具です。終了したプロセスは自分のタイマーを動かせません。また、トンネルの背後のアプリケーションが応答するかについては何も言えません。やり取りは VPN の両端の間で起きるからです。役割、想定される中断、再認証の挙動を確認せずに別の導入からタイムアウトの組をコピーすることが、安定したトンネルが揺らぎ始める道です。

サービス管理が所有するもの

デーモンが終了すれば、それを起動した管理が次を決めます。失敗を条件とする再起動ポリシーに遅延と起動レートの制限を組み合わせれば、クラッシュループをフォーク爆弾にせずに扱えます。その設定はプロセスの結果とタイムアウトに反応するもので、生きているが役に立たないプロセスは検出しません。それはより広いポリシーで埋める隙間ではなく、ライフサイクルと生存性の境界です。

所有権は設定と同じくらい重要です。デスクトップのネットワーク管理が起動した接続は、その管理の復旧の取り決めを保つべきであり、同じインターフェースに競合するサービスユニットを足すと、一つのトンネルに二人の所有者ができます。どちらか一方を選び、どちらなのかを書き留めてください。

予定された再起動が正当になる場合

時刻による再起動は合理的な保守作業になり得ます。所有者、時間枠、名前のあるインスタンス、独立した入口があるからです。しかし、決まった時刻に全員を切断するような一般的な信頼性ポリシーにはできません。

既知のリークや固まった状態を回避するために再起動があるのなら、ユニットの説明にそう書いてください。そうしなければ、次の人がそれを永遠に残します。

重要なケースを試してください。プロセスが動いたままピアが消える、プロセスが終了する、再試行に新しい資格情報が要る、アプリケーションが壊れたままトンネルが戻る。どの構成要素が反応し、どんな状態を残すかを見ます。

正しい問いは、どれくらいの頻度で再起動するかではなく、何が最初に障害に気づくべきかです。