1つのVPNログにある3つの時計：クライアント、ゲートウェイ、コレクター

VPNインシデントのタイムラインは、数分ずれた二つのタイムスタンプと、別の時刻を示す表示から始まることが多いです。誘惑は、一方を正しいと決めて他方を書き換えることです。異なる時計が異なる出来事について書いたものなので、どちらも正しい可能性があります。VPNの時計は一つというのは神話であり、作業はどのコンポーネントがどのフィールドを書いたかを見つけることです。

神話：VPNの時計は一つ

クライアントは接続を試みたときに出来事を書きます。ゲートウェイはその試行を受け取るか受け入れたときに出来事を書きます。コレクターはゲートウェイのメッセージを受け取ったときに到着時刻を書きます。これは三つの出来事であり、それぞれは書いたコンポーネントが信頼した時計で刻まれます。それらを一本のタイムラインにまとめるのは、説明しようとしている不一致を隠す便利さです。

数値は通常、秒から分の範囲で異なり、それは正常です。重要なのは、その差が配送遅延なのか、時計のずれなのか、本当に別の出来事なのかです。どれを見ているかを決めるには、各フィールドの発生元が必要であり、どのマシンが正しいかについてのより強い意見ではありません。

値より先に発生元を読む

値を比べる前に、それぞれを誰が生成したのか、どのフィールドなのかを特定します。syslogメッセージは発生元のタイムスタンプを運び（RFC 5424 が説明しています）、この形式は同期と精度を記述する時刻品質の情報も運べます。同じ形式は、システム時刻を読めないときに発生元がタイムスタンプをまったく送らないことも許し、それ自体が有用な信号です。

journalctl -o short-iso --utc -n 20
logger -t vpn-check "test event"

クライアントはアプリケーションのメタデータとして時刻値を送ることもでき、それを保存するサービスは、独立に検証済みとして扱うのではなくクライアント報告としてラベル付けすべきです。そのラベルが証拠と主張の違いです。ケースのためにログをエクスポートするときは、フィールド名、発生元、ずれを一緒に保ちます。使いやすいローカル時刻に落とすと、必要な情報そのものが壊れます。

どのコンポーネントがフィールドを書いたか言えないなら、止まってください。それを他の何かと比べるのは推測です。

タイムゾーンの表示は別の瞬間ではない

同じ瞬間を10:00Zと18:00+08:00で表示することは不一致ではなく、そう扱うと半日を無駄にします。比べる前に両方をUTCに変換し、元のテキストを変換の隣に保ちます。片方が小数で片方が整数秒というのも衝突ではありません。精度は正確さではなく、ミリ秒を持つ値でも数分ずれた時計から来ることがあります。

date -u +%FT%TZ
timedatectl

配送遅延はもう一つのよくある説明です。ゲートウェイは接続を受け入れた時刻を記録し、コレクターはメッセージが届いた時刻を記録するので、その間の隔たりは転送時間です。その隔たりはログパイプラインについて語るもので、VPNセッションについてではありません。到着時刻としてラベル付けすれば、出来事の時刻と競合しなくなります。

証拠を書き換えずに関連付ける

元のタイムスタンプを保ち、共通の見方が必要なら派生列を追加します。後のレビュー担当者が確認するのは元の記録なので、元のレコードを編集するのではなく変換をメモで説明します。コレクターの到着時刻は、存在するところでは必ず別に保存します。

chronyc tracking
journalctl --utc -u openvpn-client@work -n 50 --no-pager

端末の時計を変えることはプライバシーの制御ではなく、別のシステムがすでに持つ記録を書き換えません。また、サポートの証拠を比べにくくし、時刻に依存する証明書とコードの検査を壊すことがあります。通常運用のために時計を同期させ、意図的なずれは調査すべき障害として扱います。二つの記録が順序から外れて見えるなら、新しい経緯を組み立てる前に時計の同期と配送を確認します。

手放すべき神話は、VPNの時刻が一つというものです。各フィールドを何が書き、それが書いたときに何が起きたかを問えば、タイムラインは矛盾ではなくラベル付きの観察の集まりになります。