同じIKEv2 IDを二台のiPhoneに？交互に接続を奪い合う

二台のスマートフォン、一つのプロファイル、そしてゲートウェイを観察するまで超自然的に見えるパターン。一方がトンネルを保持し、二台目が接続すると、一台目は数秒でそれを失う。一台目が再接続し、二台目が切れる。バッテリー節約、Wi-Fiローミング、キャリアNATが疑われるが、本当の原因はほかのすべてと一緒にコピーされたテキストフィールドにある。IKEv2はpeerを名前で識別し、両方のスマートフォンが同じ名前を提示している。

IDはサーバーがあなたを保管する際の鍵だ

IKEv2の交換では、各側が自分が誰かを表明する。開始側はローカル識別子を送り、応答側は自分の識別子で応答し、応答側は開始側が主張したIDをポリシーに照らして検査する。ゲートウェイはデバイス単位ではなくID単位で状態を保持する。デバイスはゲートウェイが見えるものではないからだ。したがって同じ識別子を持つ二台は一つのpeerとして到着し、二回目の交換は一回目を上書きしなければならない。問題は両方が使用中のときだけ現れる。だから一台だけのテストでは決して再現しない。

これはクライアントのバグではない。クライアントはプロファイルに指示されたとおりに送っただけだ。

ゲートウェイから見た衝突の形

両方のスマートフォンが起きて使用中のときにpeerリストを見る。衝突では、端末が入れ替わるたびにアドレスが変わる一件のエントリだけが表示され、アクティブセッションのカウンタは二に達しない。オンデマンドの切断は見え方が違い、両者を区別するには理論ではなく一回の観察が必要だ。

起きている間に両方のイベントをタイムスタンプ付きで記録する。もう一方の端末の接続と一致する切断は識別子を指し、最後のパケットから一回のアイドル間隔後に来る切断はタイマーを指す。

重複はどこから来るのか

動作する設定を一つエクスポートし、サーバーアドレスだけを編集すると、一つ目のファイルのIDが残った二つ目のファイルができる。これがこの不具合への通常の道筋であり、小規模なグループを急いで導入するときによく起こる。

フィールド名のせいで見落としやすい。リモート識別子はスマートフォンが期待するゲートウェイを指し、それをコピーするのは正しい。ローカル識別子はこの端末をゲートウェイに対して指すのであり、その値をコピーすることが問題のすべてだ。

端末ごとに値を発行する

端末に固有で寿命を通じて安定したものを使う。たとえば在庫管理のデバイス識別子や、管理システムが登録ごとに生成する値だ。部署ラベル、共有サービスアカウント名、ユーザーのメールアドレスは、その人に二台目がある時点でどれも衝突する。

一つのファイルを配布するのではなく、端末ごとにペイロードを生成する。どの値がどの端末に属するかを記録し、交換時に古いプロファイルを復元して新しい端末を同じ衝突に戻さないようにする。

サーバー側も確認する。IDを固定のトンネルアドレスにマッピングするゲートウェイでも、二つの異なる識別子が同じ割り当てを受けると衝突する。プールに余裕があり、割り当てがユーザーごとに固定されていないことを確認する。

両方のスマートフォンを起きた状態で検証する

一台目を接続してプライベートリソースに到達し、二台目を接続して両方を一分間アイドルにする。両方のセッションが維持され、peerリストに二つのIDが表示されるはずだ。その後、各端末をロックして解除し、アイドルのケースがまだ正しく動くことを確認する。

それでも一つのセッションがほかに何も接続していないのに一日に一度切れるなら、IDはもう容疑者ではない。プロファイルを再編集するのではなく、アイドルタイマーとサーバーのセッション上限に進む。