IPsec プロファイルにおける五つのアドレス役割と、どれが誤りか

典型的な接続定義では五つの異なる役割がアドレスを受け取り、それらは互いに一致する必要はありません。管理者が行き詰まるのは、すべてのフィールドを同じホストに向けるというもっともらしい直感が、少なくとも三つにとって誤りだからです。出口は、まず症状を名指しし、次にそれを生み得る一つか二つのフィールドを見ることです。

五つの役割を、重要な順に

トランスポートのエンドポイントは、IKE 交換が届けられる場所です。認証された ID は各側が証明する名前であり、ルーティングテーブルではなくポリシーに対して照合されます。保護サブネットは、どの内部トラフィックがトンネルに属するかを決めるセレクタです。次に、ゲートウェイ自身が会話を始めるときに使う送信元があり、最後にピアへ到達するためのアンダーレイのネクストホップがあります。

left や right といった参加者ラベルは接続の二辺のための慣習であり、ローカルとリモートの同義語ではありません。あるキーが別製品で意味したことをそのまま意味すると決めつける前に、実際に導入されている実装のマニュアルを読んでください。

判断その一: 何も確立しない

ログに交換がまったく現れない場合、最初の容疑者はエンドポイントです。誤ったアドレス、フィルタされた経路、あるいはデーモンが待ち受けていないインターフェースです。ハンドシェイクが見えてから ID のフィールドに移ってください。ID は交換の内部で判定されるもので、その前ではないからです。フィルタされた経路と誤ったアドレスはクライアントからは同じに見えるので、何かを編集する前に待ち受け側を確認します。デーモンが想定どおりのインターフェースに束縛されていることを確かめてください。一つのアドレスで待ち受けるサービスは、遮断された経路とまったく同じに見えるからです。

変換を経て観測された公開アドレスは、ピアが証明する ID と同じものではありません。遠端でのパケットキャプチャが示すものに合わせてアドレスを変えるのは、よくある誤った修正です。

判断その二: トンネルは上がっているのに通信が死ぬ

セレクタはトンネルに入るものを決めます。ここで食い違うと、ネゴシエーションは成功するのにアプリケーションは失敗し続ける接続が生まれます。遠側はあなたの保護範囲を自分のリモート範囲として指定しなければならず、まさにそこで逆転した値が紛れ込みます。

編集する前に両方の設定を並べて読んでください。一方のホストのローカル範囲は他方のリモート範囲であり、一組の入れ替わりが何も運ばないトンネルを説明します。キーに触れる前に組を絞り込みます。トンネルの内側に一つ、外側に一つのサブネットを置けば、セレクタとルーティングのどちらが原因か分かります。

判断その三: ゲートウェイ自身の通信だけが失敗する

クライアントのために転送される通信は完璧に動くのに、ゲートウェイ自身が始める要求は失敗することがあります。そのフローには引き継ぐクライアントの送信元がないからです。優先送信元の設定はまさにこの場合のためにあり、送信元変換ではありません。書き換えるのではなく、送信元アドレスを選ぶのです。

別のアドレスを明示的に束縛するアプリケーションは優先設定を上書きできます。設定が無視されていると結論する前に、パケットの実際の送信元を確認してください。設定の意図を信じるのではなく、ゲートウェイ自身のインターフェースでキャプチャします。

ネクストホップはローカルな指示

アンダーレイのネクストホップはこのホストにピアへの到達方法を伝えるもので、遠側に同じ値は必要ありません。これを共有設定として扱ったり、デフォルトゲートウェイを固定したりすると、経路が変わった瞬間や第二の経路が現れた瞬間に破綻します。

実装によってはここに特別な値があります。導入済みのバージョンについてマニュアルが挙げているものが唯一の安全な答えであり、ローカルのルーティングテーブルがそれが機能した証拠です。ピアに名前では届くがアドレスでは届かないとき、その食い違いこそが発見であり、回避すべき些事ではありません。

プロファイルを両端から読む

紙の上で役割を反転させるのが最速のレビューです。保護範囲を入れ替え、各側自身のネクストホップと各側自身の ID を保ちます。入れ替えに耐えないものは、おそらく誤った役割に割り当てられています。

次に役割ごとに一つのフローを試します。ピア間の到達性、内部クライアントのフロー、ゲートウェイ発の要求です。三つのテストで、設定を開き直さずにどの役割が誤って割り当てられているか分かります。結果は変更したフィールドの隣にチケットへ書き添えてください。次のエンジニアが同じプロファイルに出会うからです。