2秒間の停止：VPNかWi-Fiか
2秒の停止と新しいVPNセッションは別の出来事です。タイマーを変える前に、アクセス経路とトンネルを別々の時間軸に置いてください。
二秒で自然に回復する停止は、トンネルが再ネゴシエーションしたのか、無線がつまずいたのかに関係なく同じに見えます。何も落ちていない可能性もあり、その可能性をまず試す価値があります。短い損失のバースト、再ネゴシエーション、アプリケーションの停止は、キーボードを打つ人にはどれも同じに感じられます。三つのうち設定変更で直るのは一つだけです。
記録は二つ、一つではない
下の接続に何が起きたかと、トンネル自体が何をしたかを別々に書き留めます。そのうえでアプリケーションの停止を両方の記録に突き合わせます。これらは時に一致する独立した出来事の系列であり、三つすべてを切断と呼ぶのは最初から答えを決めていることになります。
一分に一回しか調べない監視では、二秒の中断は見えません。その日を健全と報告することは技術的には正しく、実用上は無意味です。引用するすべての結果のそばにサンプリング間隔を書いてください。
アプリが止まった間にアクセス回線がしたこと
サンプリング間隔とタイムアウトが、監視がそもそも観測できたものを決めるので、両方を結果のそばに記録します。計測器が六十秒ごとにサンプルを取るなら、障害がなかったという記録の意味は小さいものです。次に、タイムスタンプ付きで三か所（ローカルのルーター、通常の経路で到達する承認済みの外部ホスト、トンネルの向こう側のリソース）を調べます。
公開された宛先自体がトンネル経由でルーティングされているとアクセス経路ではなくトンネルを測ってしまうため、まず経路を確認します。障害を実際に日時で特定する証拠は、ルーターのリンクイベント、モデムの再同期記録、変化したWANアドレスという一層下の記録です。累積エラーカウンタは何かが起きたことは教えますが、いつ起きたかは決して教えません。それらの記録は単独で読むのではなく、インシデントの時間枠と相関させてください。
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address show昨日増えたカウンタは、今朝の停止について何も説明しません。相関の範囲は、ユーザーが報告した時間枠に限ってください。
再起動の記録を探す
UDPデータグラムが一つ落ちただけで、Community OpenVPN が新しいTLSネゴシエーションを始めるわけではありません。再起動の挙動は ping-restart に従い、有効な値はサーバーから押し付けられた可能性があり、2.6のマニュアルがそれらのタイマーを定義しています。配信は一瞬途切れ、しきい値は決して超えず、ログは空のままです。ですから停止前後のログで、再起動の行、新しい接続、変化したセッション識別子を探してください。三つのどれも現れなければ、トンネルは何もしておらず、タイマーは最初から問題ではなかった可能性が高いです。
keepaliveを短くすると検出が速く見え、ちょっとしたつまずきが再接続になる境界が動きます。再接続のたびに認証の一巡と経路の再設定がかかります。タイマーを伸ばすと、死んだ経路がまだ生きているように見える時間が延びるだけです。どちらも代償のある調整であり、無料の改善ではありません。
起きなかった出来事も証拠であり、ログのどこも注目を引かないために飛ばされがちな種類です。実行した検索そのものを記録し、結果だけを書かないでください。
何を直すかは比較に決めさせる
両方の記録を並べれば、割り当てはたいてい自然に決まります。両方の経路でルーターのリンクイベントがあれば、主題はアクセス接続です。静かなトンネルと使える通常経路なら、主題はネゴシエーションです。
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
各行は手がかりであり判決ではなく、端点はICMPの優先度を下げ、二つの宛先が同じ経路を共有するとは限りません。比較を可能にするため、クライアント、ゲートウェイ、アプリケーションの時計を揃えてください。二列に当てはまる行には、判断ではなくもう一つの観測が必要です。
レビューに耐える報告は、停止がどれだけ続いたか、どの経路が応答し続けたか、その秒にトンネルが何を記録したか、監視がどれだけ頻繁にサンプルを取るかという四つに答えます。この四つの事実があれば、次の読み手は要約を信じるのではなく観測を再現できます。稼働率は、あなたが気にしている間隔をまさに隠し、「VPNが落ちた」という表現も同じです。