鍵がローテーションするたびに VPN が切れる理由

接続は一時間動いてから切れ、クライアントは disconnected より役立つことを何も報告しない。その周期こそが手がかりで、更新の交換には最初のハンドシェイクと違う点がある。タイマーは、いつそれに遭遇するかを決めるだけだ。最後のラベルではなく、その交換のメッセージを保存しよう。

ラベルではなく段階を読む

IKEv2 では IKE アソシエーションと CHILD アソシエーションが別々のスケジュールで更新される。最初のネゴシエーションで受け入れられた提案が、二回目でも自動的に受け入れられるわけではない。一方が完了しても他方が拒否され、半分だけ存在するトンネルができる。クライアントのログ行ではなく、その交換を所有するツールで取得しよう:

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

OpenVPN では、相当する出来事はバージョンと配備設定に左右される再ネゴシエーションだ。その認証の振る舞いには独自の失敗の型がある。重要なメッセージは失敗した段階を名指しするので、チケットで言い換えるのではなく逐語で記録すべきだ。

タイムスタンプも書き留めよう。最後に成功したネゴシエーションから一定間隔で落ちるのは、利用中に不規則に来る落ち方とはまったく別の所見であり、その間隔が生き残る唯一の証拠であることも多い。

失敗する提案を比較する

拒否された提案は応答側に明確なメッセージを出す。よくある原因は両端のアルゴリズム・鍵長・グループ・寿命の違いだ。最初の CHILD ネゴシエーションが成功したのは相手側が開始したからかもしれず、その場合は相手側の提案リストが使われている。何かを変える前に両端を見よう。

寿命の不一致は、片端で余裕に見えた値がもう片端に完了できない更新を始めさせるから、特に注意に値する。鍵更新の動作に関するドキュメントは、アソシエーションの更新がどう起動され、両端の時間の期待がどう食い違いうるかを説明している。設定ファイルが示すものではなく、各端が対応すると主張するものを比べよう。

古いプロファイルやプロバイダのテンプレートは、現行リリースがもう提供しない提案を固定してしまうことがある。不一致は新しいネゴシエーションを強制したときにだけ表面化する。

資格情報の問題と到達不能なピアを切り分ける

認証で失敗する更新は、クライアントでは似て見え、サーバーではまったく違って見える。再ネゴシエーションで資格情報が再確認されるなら、期限切れの証明書・失効したアカウント・変更されたパスワードは、以前の接続がすべて成功していても、ちょうど更新の間隔で切断を起こす。到達不能なピアは第三の可能性で、拒否はまったく出ず、パケットは出て行って何も応答しない。その場合はタイマーではなくネットワークの変化に従うので、失敗がローミング・アイドル期間・経路変更の後に来るかを確認しよう。

三つは遠端が記録した内容で見分ける。理由付きの拒否・認証失敗・沈黙は三つの異なる対処だ。クライアントを再起動すると、それらは一つの役に立たない観察に潰れてしまう。

ネットワークを責める前に、証明書の日付とアカウントの状態を確認しよう。どちらも調べるのは安く、どちらもクライアント自身のメッセージには見えない。

更新を一度強制して結果を読む

次を一時間待つのではなく、事業者が対応する方法で更新を一度強制しよう。その間も必要な失敗ポリシーは保ったままにする。検証を切ったり寿命を一日に伸ばしたりすると、何も直さないままログから症状が消える。次の人のために、より長い障害を残すことにもなる。

修正が入ったら、更新されたトンネルを確認し、そのうえでアプリから新しい要求を出そう。アソシエーションが変わったときに生きていたアプリのセッションは、トンネルが再び健全でも独自の回復が必要かもしれない。利用者はそれを、VPN がまだ壊れていると報告するだろう。

リリースのバージョン、交渉されたタイマー、失敗した段階を記録しよう。そうすれば次の再発は、記憶から書き直すのではなく、これと比べられる。