VPNが同じ間隔で切断される？タイマーを突き合わせる

十五分ごと、または毎時同じ分に切れるトンネルは、ネットワークが不安定なのではなく、何かのタイマーが切れたことを教えています。有用なのは間隔を書き留め、このパターンを生む四つのタイマーと比べることです。その比較の前にタイムアウトを変えると、たいていは原因を説明しないまま障害が移動し、次の発生が最初より読みにくくなります。測定は十分で済み、一週間の推測を置き換えます。

間隔を数値にする

五、六回の発生を集め、その間の間隔を計算します。一日の始まりからの間隔ではなく、09:12、10:12、11:12の切断は毎時の境界、09:12、09:27、09:42の切断は最後の成功した接続から十五分です。結果は最も近い分ではなく、最もありそうなタイマーに丸めます。

各イベントにつき、トラフィックが最後に動いた時刻と、クライアントが切断を報告した時刻の二つを記録します。トンネルが静かに死に、クライアントが次の送信で初めて気づくとき、この二つはずれ、その差こそがアイドルタイムアウトとハード障害を分けます。気づくのが遅いクライアントは、測定するアイドル窓を大きく見せます。

再接続が自動かどうかを確認します。数秒で再接続するクライアントは、間隔をログに残したままユーザー報告から外すので、こうした障害は周期的ではなく時々起きると説明されがちです。また、ノートパソコンを使っている本人からもイベントを隠します。

似て見える四つのタイマー

繰り返すトンネル切断のほとんどは、プロトコルの鍵更新、アイドルマッピングの失効、DHCPやインターフェースのイベント、アカウントポリシーのどれかから来ます。違いは、トラフィックが流れていたかどうかと、境界でログが何を言うかです。

以下の兆候は覚えておく価値があります（一つのログ行から三つの説明を退けられるため）：

最初の行は仕事をしているセキュリティ機構で、二番目は状態を忘れる中間機器です。両者を混同すると、鍵更新を弱めるか、関係のなかったファイアウォール規則を追いかけることになります。

ビジーかアイドルかで、どちらの半分かがわかる

トンネル内のホストへの長いストリームなど、連続トラフィックで統制のとれた比較を行い、間隔が変わるか見ます。データが流れている間に切断が消えるなら、タイマーはアイドル基準です。

連続トラフィックでも残るなら、原因は鍵更新、リース、ポリシーの側です。この一つの試験で、約一時間の観察で候補の半分が消え、かかるのは注意力だけです。

試験中はアクセスネットワークを変えないでください。比較の途中でWi-FiとEthernetを切り替えると、タイマーと区別したいインターフェースのイベントをちょうど持ち込みます。

ログ行を境界に突き合わせる

記録した時刻の前後のクライアントログとサーバーログを、ファイル全体ではなく読みます。鍵更新は交渉を示し、アイドル失効は次のパケットまで何も示さず、リース変更はアドレスの作業を示し、ポリシー上限は通常きれいな管理上の切断を示します。

次のコマンドは各ソースから該当する窓を取り出します：

grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show

三つのソースがタイムスタンプで一致すれば、タイマーの持ち主がわかります。クライアントログにだけ何かがあるなら、セッションを終えているのはおそらくサーバーではありません。

直すのは段階で、アイコンではない

持ち主ごとに支持される修理は一つです。鍵更新の失敗には両端で互換の提案が要ります。アイドル失効にはキープアライブか短いアイドル期待が要り、経路が許す範囲です。リースのイベントにはインターフェースか電源設定の手当てが要ります。アカウント上限はポリシーの決定で、不具合ではありません。

アイコンを緑に保つために鍵更新や認証を切るのは、見える切断を見えない弱点と交換することであり、トンネルが最後に新しい鍵を交渉したのがいつか言えなくなります。その後で元の時間を再試験し、タイムスタンプを残せば、次を最初からやり直すのではなく今回と比べられます。