up と down フックで OpenVPN クライアントの稼働時間を測る方法

ダッシュボードは接続がどれだけ続いているかの数値を求めますが、OpenVPN はそれを提供しません。クライアントはトンネルが立ち上がった時刻を知っていますが、セッション状態が失われる前に誰かがその瞬間を記録した場合に限ります。対応している場所は up フックであり、保存する価値のある値は整形された文字列ではなく生の epoch 秒です。その後はすべて算術で、加えて数値が正確であり続けるかを決めるいくつかの順序規則があります。

フックが実際に動くことを確認する

その周りに何かを設計する前に、フックが発火することを証明します。最小限のクライアント設定には script-security 2 と明示的な up および down のパスが必要で、セキュリティ行がないと OpenVPN はスクリプトの実行を拒否し、そのことをはっきり告げます。さらに up-restart と down-pre を同時に追加して、再起動と切断の経路が予測どおりに動くようにします。

フックの最初の版は、自分の環境をファイルに追記するだけで他は何もしないようにし、これでビルドが実際にエクスポートする変数名が分かります。たとえば dev や script_type、別の版で覚えている名前ではなく実際の名前を使えます。接続を一度、切断を一度実行してから、ファイルを読みます。何も現れないなら、決して動かないフックの上に載せた設計が何週間も監視の不具合に見えるので、ここで止めてください。

フックがどのユーザーとして動くかを確認します。user と group を設定すると、OpenVPN はスクリプトを実行する前に権限を落とすため、root が書き込めるディレクトリがフックには閉じていることがあります。パスは自分のシェルではなくサービスの視点で選びます。

epoch の値を一つ記録し、意図的に消す

up フックに必要なのは次の一行で、date +%s > /run/openvpn-client.started パスはインスタンスごとに調整します。epoch の値なら後から言語・時間帯・書式の問いを避けられ、監視エージェントが自分の時計と比べられるのと同じ数値になります。

消すことは書くことと同じくらい重要です。down フックはファイルを空にするか削除すべきで、down-pre がそれをインターフェースの閉鎖前に行い、すでに消えたトンネルをファイルが説明している窓をなくします。up-restart は内部再起動のときに刻印を更新し、元の値をそのまま残しません。この組がないと、ping タイムアウト後の再起動 はトンネルが再確立している間も上がり続ける数値になります。

寿命の正しい場所を選びます。/run の下のファイルは再起動で消え、これは現实と合いますが、一方で /tmp の下のファイルは予測できない形で掃除されることがあり、設定ディレクトリのファイルは誤解を招く形で残ります。権限を設定して、サービスのユーザーと監視の読み手だけが読めるようにします。

ログ行を信用せずに稼働時間を計算する

保存された秒を読み、現在の秒を読み、引きます。ファイルがないか空のとき、正直な答えはトンネルが動いていないということで、稼働時間がゼロということではありません。この二つの状態は別の警報を出すべきなので、生の秒は監視のペイロードに置き、日と時間は表示層で整形します。エクスポーターの中で丸める整形器は、障害のときに誰かが欲しがる精度を捨ててしまいます。

ログの時刻印を解析するのは魅力的な近道ですが、書式は設定されたどのオプションにも従い、ローテーションは履歴を消し、再接続は一つの連続したトンネルではなく別々のセッションとして現れるので、三つの点で失敗します。フックは出来事を、起きたその瞬間に一度だけ記録します。

検査が別のホストで動くときは、継続時間ではなく時刻印を送り、読み手が自分の時計を当てはめるようにします。すると小さな負の結果は壊れたフックではなく時計のずれとして読めます。

再接続、再起動、複数インスタンスを扱う

一つのホストに二つのトンネルがあれば二つのファイルが必要で、鍵はサービスがすでに使っているインスタンス名です。パスを共有すると、最新の接続がすべてのプロファイルの開始時刻を上書きし、症状は二つ目のトンネルが始まったときに数値が後ろへ飛ぶことです。

再接続の挙動は、もっともらしい設計が静かに間違ったことを報告する場所なので、独自の試験に値します。相手を落とすかプロセスに信号を送って再起動を強制し、それからインターフェースの状態とファイルを比べます。トンネルが戻った瞬間に時刻印は前に進むはずです。

サーバー側では、状態ファイルがクライアントごとに connected-since の値を持ち、サーバーがその相手を最後に見たのはいつかという別の問いに答えます。それが説明するセッションと一緒に消えるので、置き換えではなく照合に使いましょう。どちらの測定も、トンネルの後ろにあるアプリケーションの健全性については何も言いません。

順序の不具合を捕まえる三つの検査を実行する

通常の接続、強制の再接続、きれいな停止を試し、それぞれの後にインターフェース一覧とファイルを一緒に読みます。きれいな停止の後にも残っている刻印、またはインターフェース一覧にないトンネルを主張するファイルは、フックの順序をまっすぐ指しています。root のシェルは別のファイルを見て自信たっぷりに間違った答えを出すことがあるので、検査はサービスのユーザーとして、サービスのパスで実行します。そのあと遅いポーラーにファイルを読ませ、決して書き込まないことを確かめます。

六十秒ごとの問い合わせで警報は足りますし、どのフックもそのポーラーが生きていることに頼るべきではありません。この二つの責務を分けておけば、どちらかの側を再配備しても数値は信頼できるままです。