IKE ID とエンドポイントアドレス：混同しないこと

FQDN ID というラベルの付いたフィールドは、公開アドレスの逆引き DNS 名を求めるものではなく、文字列そのものとして読んでください。strongSwan のパーサではまさに文字列であり、読んでもエンドポイントに解決されることはありません。この事実だけで、ピアの識別子を選ぶときに最もよくある混乱が消えます。以下の確認項目は、関係する三つの値が一つに溶け合うのを防ぎます。

ラベルは検索ではない

ベンダーの画面は FQDN や hostname といった言葉を緩く使っており、筐体のラベルはその背後にあるエンコードについて何も語りません。フィールドを Client FQDN と呼ぶ機器でも、FQDN やメール形式の文字列、裸のアドレスを送ることがあります。テキストと型を二つの別の判断として扱い、両方を記録してください。

文字列としての ID に DNS は不要です。相手側が確認する主張であって、ネットワークが解決すべき名前ではありません。

三つの値は別々に書く

設定画面は一つでも、その背後には三つの役割があり、それらを混ぜると高くつく誤りになります。一つはパケットの行き先を決めるエンドポイントアドレスです。もう一つはこのピアが提示するローカル ID、三つ目は認証を実行する前に遠端へ期待する ID です。変更チケットには三行で書き、それより少ない記述では関係ではなく VPN を説明することになります。

例に挙げた ID は、導入の一環として選定し承認する必要があります。それらは認証が検証する主張であり、どのピアも信頼できるようにする資格情報ではないため、もっともらしい文字列は何も承認しません。

型は値の一部

strongSwan の ID リファレンスは FQDN、メール形式の値、IP アドレス、その他のエンコーディングを区別するため、エンコーディングは文字と同じくらい重要です。二台の機器が同じテキストを異なる型で受け入れても、互いを拒否することがあります。型を書かずに値を記録したメモは設定の半分です。

その機器が実際にどの型を送るのかをベンダーに確認し、画面のラベルではなくデコード結果で裏付けてください。推測した型は、次の変更を待つ不一致です。

双方が相手を満たす必要がある

各側のローカル ID は、相手側の認証ポリシーを通過しなければなりません。両方の機器のすべての ID 欄に同じ文字列を貼るのとは違い、その近道は誰もデバッグできない設定を生みます。

証明書認証は、証明書の ID と信頼条件が入力した IKE ID の隣に並ぶため、独自の要件を追加します。IKE ID の一致だけでは証明書ピアを承認しません。

DNS が効く場面と、バージョンが強制するもの

検出に使うゲートウェイの hostname には確かに動作する DNS が必要で、その要件は入力した ID の逆引きではなくエンドポイントの発見に属します。検出の失敗と ID の不一致はクライアントログで似て読め、直す場所も異なるため、チケットでは両者を分けてください。

型を強制する構文をコピーする前に、実際に動かしている製品とバージョンのパーサを読んでください。古い strongSwan のリリースは挙動が違い、他のベンダーも独自の制約を加えているからです。両端を比べるときは、期待する ID、提示された ID、型、認証エラーの四つを一緒に押さえれば、不一致は意見ではなく証拠になります。