VPN の復旧が障害より長くかかる理由

Wi-Fi は三十秒前に戻ったのに VPN はまだ落ちていて、クライアントが壊れたように見えます。多くの場合、それは独自の再試行スケジュールに従っているだけで、そのスケジュールはネットワークが今戻ったことを知りません。そのずれがすべてです。復旧時間は障害に、クライアントがすでに受け入れた待ち時間を足したものです。すべてのタイマーを下げるのが一つの対応で、どのタイマーが重要かを理解するのがもう一つです。

調整が効くかどうかは三つの条件で決まります。どの段階が遅いのか、失敗がそもそも再試行可能か、そしてネットワークが戻ったことをクライアントがどう知るかです。

三つに見える三つの待ち

エンドポイント解決、IKE または TLS のネゴシエーション、パケットの再送、そして新しい試行の開始は、それぞれ別のタイマーを持つ別の出来事です。strongSwan は IKE 向けの再送バックオフを文書化しており、OpenVPNは異なる意味論を持つ独自の再試行制御を持っています。一方の数値をもう一方へコピーするのは、仕組みが同じだという前提に立っていますが、実際は同じではありません。どの間隔を見ているのか決める前に、ログの順序を読んでください。

ログの静かな一分は、必ずしも停止したプロセスではありません。設定どおりに動いている指数バックオフである可能性があります。

実際に遅いのはどの段階か

ログが認証エラーで失敗する試行を示しているなら、資格情報が誤っているため、タイマーの変更では何も解決しません。試行がまったく行われていないなら、クライアントは待機ウィンドウの中にあり、スケジュールが解決策です。試行が行われてタイムアウトするなら、問題は到達性かリスナーの不在であり、速く再試行してもログが埋まるだけです。これら三つの状態にはそれぞれ別の担当があり、タイミングの問題はそのうち一つだけです。

数値に触れる前に、失敗を分類してください。

タイマーを下げることが効くときと効かないとき

短く頻繁な障害のあとの待ちが主なコストであるときは、再試行の上限を下げてください。たとえばアクセスポイント間を移動するノートPCの場合です。障害が長い、またはまれなときはそのままにしてください。攻撃的な再試行は、コンセントレーターが最も応答しにくいまさにその瞬間に負荷を加えます。どちらの場合も、パラメーターを一つ変えて記録し、改善したと決めつけずに次の復旧を測定してください。

すべてのプロファイルにコピーされた非常に短いタイムアウトは、測定を伴わない調整の典型的な結末です。

クライアントを責める前に準備状況を確認する

クライアントは、何かが試すまでネットワークが使えることを見えないことがよくあります。キャプティブポータル、DHCP の更新、ルートの変更は、そのどれかが起きる前に設定されたスケジュールで待たせることがあります。オペレーティングシステムのネットワーク状態の変化とクライアントの次の試行を同じ時計で見れば、どちらの待ちなのかが分かります。手早い方法は、ネットワーク準備完了イベントのタイムスタンプと、その後の最初の試行のタイムスタンプを記録することです。

待っている間も直接のトラフィックが遮断されたままであることを確認してください。トラフィックが漏れる速い再接続は改善ではありません。

何を記録するか

どのタイマーが、どの値からどの値に変わったのか、その後復旧がどう見えたのかを書き留めてください。クライアントのバージョンも記録してください。既定値はリリースごとに動き、文書化されていない非常に短いタイムアウトは次にプロファイルを読む人を混乱させます。

その記録が、次のソフトウェア更新を実験ではなく比較に変えます。