DPDタイマーを短くしてもVPNフェイルオーバーは速くならない

トンネルは落ち、復旧には九十秒かかり、デッドピアタイマーは十に設定されている。だからタイマーが責められる。その推論は、検出後に起こり、通常は時間の大半を占める三つの段階を飛ばしている。生存検出が沈黙に気づき、その後ピア選択、認証、ルートのインストール、アプリケーションの再接続がそれぞれ順番に時間を取る。最初の段階を短くしても他の段階は短くならず、すでに苦しんでいるシステムに混乱を加えることになる。

四つの段階、そのうち一つだけは計測できる

復旧をタイムスタンプ付きの四つの出来事として書く。障害は観測可能になる：最後の有用な保護トラフィックと最初の失敗した要求。所有するメカニズムが反応する：生存検出、ルートモニター、その他の文書化されたトリガー。代替が使えるようになる：ピア選択、認証、新しいアソシエーション、そして意図したトラフィックを実際に運ぶルート。アプリケーションが復旧する：新しい操作が成功し、進行中だったものに定義された結果が生じる。

IKEv2の生存規則はピアとその交換に関する証拠を述べるもので、そのピアの背後のデータベースやファイルサービスについては何も語らない。生存タイムアウトを経路全体の健全性チェックとして読むことが、タイマー探しを始める誤りである。

タイマーが最も面白くない数字である理由

設定値は交換可能な単位ではない。再試行間隔もあれば、試行の上限もあり、他と並行して動くものもある。それらを足し合わせると、予測のように見えて噂のように振る舞う数字ができる。これから触るフィールドの文書を読み、三種類のどれなのかを確認する。

他の段階はタイマーですらない。再接続のバックオフ、対話的な認証プロンプト、再起動時にしか設定を再評価しないクライアントは、どれも障害を支配しうる。その間、プロトコルのタイマーはどれも快適に低いままだ。

実際に遅い段階を測る

障害を一度だけ、両側のタイムスタンプ付きで捕捉し、プロトコル自身のカウンターではなく四つの出来事を比較する。きちんと行った一回の観測ウィンドウは、一か月の調整に勝る。

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

代替エンドポイントが決して応答しないなら、タイマーの変更は何の助けにもならない。到達不能は検出の問題ではないからだ。新しいセキュリティ状態が素早く形成されてもルートがまだ死んだ経路を指しているなら、問題はルートのインストールにあり、さらなる生存調整は混乱を加えるだけである。

代替はすでに使えなければならない

設定で定義されたバックアップは、機能するバックアップではない。クライアントの現在のネットワークから到達でき、同じ識別情報を認証でき、同じポリシーの下で同じトラフィックを運ぶことを許可されていなければならない。障害の最中にこれら三つの欠落のどれかを見つけたら、タイマーの議論は無意味になる。プライマリが健全なうちに代替をテストすること。両方のログを並べて読めるのはその時だけだからだ。

代替を事前に用意し、プライマリが健全なうちに意図的にテストし、四つの段階のどれが時間を取るかを記録する。その記録が、次の変更を推測ではなく測定にする。

フェイルバックの混乱と管理経路

プライマリを復元するのは別の決定である。積極的なフェイルバックはバックアップで既に復旧した作業を中断しうるし、本当の障害が二つの等しい選択肢の間で揺れ続けるルートであるとき、揺れる経路は不安定なトンネルに見える。

優先順位のない二つの等コスト経路は、目に見える揺れの通常の原因である。各モニターが他方の選択に反応するからだ。通常時の優先経路を決め、その優先をルート順序に任せず設定で明示する。望ましいフェイルバック動作とその所有者を事前に定義する。以前の設定と独立した管理経路を保持すること。障害中に自分自身のアクセスを失う変更は、ネットワーク事故を現地訪問に変えてしまう。

その後、同じワークロードを繰り返し、同じ四つのタイムスタンプを比較する。同じ欠けたルートやログインをアプリケーションが待ち続ける短い復旧は前進ではなく、同じグラフ上の別の数字である。