IKEv2のデッドピア検出はアプリを検査しない

IKEv2の生存確認が問うのは一つだけです。保護された制御関係で相手ピアがまだ応答しているかどうかであり、内部アプリが健全か、ゲートウェイの先に経路があるか、閲覧が速く感じるかは測りません。トンネルの先の役立つものがすべて失敗していても、この確認は通ります。

タイマーを変える前に、二種類の証拠を別々に読んでください。

生存確認が実際に問うていること

生存確認の交換は、確立済みのIKEセキュリティアソシエーションの中で送られ、設定された時間内に応答を期待します。成功が意味するのはピアのIKE実装がまだそこにあり、まだ話す用意があること。子のセキュリティアソシエーションがトラフィックを運ぶことについては何も言いませんし、ゲートウェイの先のルーティングについても、トンネルを開いた目的のサービスについても何も言いません。これは三つの別々の問いであり、三つの別々の失敗の仕方があります。

この違いが、セッションが静かになったときにどこを見るかを決めます。データ経路が壊れているのに応答し続けるピアは、ポリシー、ルーティング、あるいは下流のサービスを指します。応答をやめるピアは、到達性か、遠端自身の状態を指します。

ブラウザより先にセキュリティアソシエーションを読む

デーモンに問い合わせると、制御の状態とデータの状態は別々に並び、カウンタは何かが試されたかどうかまで教えてくれます。一度もインストールされなかった子アソシエーションは、インストールされた後にパケットを通さなくなったものとはまるで違って見えますが、どちらも同じ利用者の不満を生みます。

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

チケットには状態名をそのまま書き、不満が出た時点のカウンタも添えます。トンネルがダウンといった説明は、二つのアソシエーションのどちらが終わったかを隠してしまい、通常はそれが唯一残す価値のある事実です。

経路の失敗は死んだピアとそっくりに見える

ゲートウェイは制御の交換に応答できますが、その間にプライベートサーバがオフラインだったり、転送経路が欠けていたり、内部の名前解決が完全に失敗していたりします。クライアントから見れば、どれもセッションは上がっているのに宛先が上がっていない形で現れます。戻りの経路は、遠端の非対称ルーティングが一方向にしか沈黙を生まないため、行きの経路と同じくらい注意して確認してください。

トンネルが上がっているかを試すのではなく、目的のアプリを直接試し、それが試したアドレスを名指ししてください。ゲートウェイへのpingはゲートウェイが応答することを証明しますが、アプリが応答したことは一度も証明していません。アプリが試した正確なアドレスを記録してください。その文字列は後で調査を狭めますし、チケットがたいてい落とす唯一の事実です。

タイマーを診断から切り離す

検出間隔を短くすることは性能の変更ではなく、容量を増やしません。パケット損失の下では、失敗がどれだけ早く認識されるかが変わり、何も良くならないのに症状の見え方だけが変わりえます。まず実際の失敗時刻を記録し、それから、持っている回線に対して許容値が間違っているかを判断してください。

NATマッピングの更新も同じ分類です。変換された経路を使える状態に保つものであり、遠隔のアプリが動いている証拠ではありません。

完全な復旧ポリシーは、ピアが死んだと宣言されたときにクライアントが何をするか、つまり再起動、切断、保持のいずれかと、その間ほかのトラフィックが何をしてよいかを定めます。それがなければ、同じ障害が四半期ごとにゼロから診断し直されます。