サイト間 VPN 経由の ASA DHCP リレー:順を追った解説
サイト間 VPN 経由の ASA DHCP リレーの三つの段階をたどります。クライアント側インターフェース、リレー通信のトンネルポリシー、giaddr への応答です。
リレーは三つの段階で動作し、VPN を通過するのは中間の段階だけです。クライアントは支店セグメントでブロードキャストを送り、ASA はそのブロードキャストを DHCP サーバーへのユニキャスト要求に変換し、サーバーはクライアントではなくリレーアドレスに応答します。この順序で各段階をたどれば、「リレーが壊れている」というほとんどの事例は、欠けているポリシーか読み違えた setroute 行に行き着きます。
第一段階:クライアント側インターフェースでリレーを有効にする
支店の ASA では、リレーはクライアント側を向いたインターフェースの性質です。サーバーは到達可能なインターフェースとともにグローバルに宣言するか、そのクライアント側インターフェースの配下で宣言してルーティングテーブルに出方向を選ばせます。この二つの形式は互換ではなく、誤った方をコピーすることが解説が脱線する最初の地点です。
何かを変更する前に実行中のコンフィグを確認します。どのインターフェースでリレーが有効か、どのサーバー形式が存在するか、setroute がクライアント側インターフェースに紐付いているか、です。ASA が別セグメント用の DHCP サーバーも動かしている場合は、いったん止めて制約の一覧を読んでください。サーバーとリレーは同じ装置で同時に有効にできません。
リレーは自身のクライアント側アドレスをゲートウェイアドレス欄に入れます。サーバーが応答するのはこのアドレスなので、ローカルだけでなく、トンネル越しに遠隔サイトから到達できる必要があります。
第二段階:ASA が生成する通信をトンネル経由で運ぶ
ここが飛ばされがちな手順です。ポリシーベースのサイト間 VPN は通常、サブネット間の通信のために構築され、リレー要求は ASA 自身が生成します。トンネルのアクセスリストとクリプトマップが支店ホストからサーバーサブネットへのフローだけに一致していると、リレーパケットはトンネルに入らない可能性があります。アクセスリストは双方向で確認してください。支店からサーバーへの行だけでは足りません。
対象通信が ASA のリレー送信元とサーバーアドレスを覆っていること、戻り方向も許可されていることを確認します。VTI ベースの設計ではルーティングの判断は単純になりますが、VTI 上のリレー対応は特定のリリースで追加されました。ASA の DHCP ガイド は 9.14(1) を示しているので、古い装置に VTI の例をコピーする前にイメージを確認してください。
ASA からサーバーへの ping だけではほとんど何も証明できません。別の経路、別の送信元アドレス、あるいはリレーのパケットが一致しないポリシーの下でも成功し得ます。
第三段階:応答と setroute オプションを読む
RFC 2131 は、そのフィールドがゼロでないとき、サーバーが応答を giaddr のアドレスに送ると述べています。したがって 戻り経路はリレーアドレスへルーティングされる必要があり、トンネルポリシーはサーバーからリレーへの方向を許可しなければなりません。要求は通ったのにオファーが届かないなら、見るべき場所はここです。
次に、似て聞こえる二つを切り分けます。setroute キーワードは、ASA がクライアントに渡すデフォルトルーターのオプションを変更または追加します。ASA にルートを設定するものではなく、VPN ポリシーを作るものでもありません。アドレスは得たのに何にも到達できないクライアントは、多くの場合トンネルではなく setroute やスコープの問題です。静的ゲートウェイを持たないクライアントで試し、オファーにどのデフォルトルーターが現れるかを見てください。
オファーを最初から最後まで読みます。提示アドレス、マスク、デフォルトルーター、DNS、リース時間です。そのうえでリースを更新させます。一度は動いて更新で失敗するリレーは、通常、最初のやり取りが隠していたスコープ、リース、戻り経路の問題を抱えています。
直ったと言う前に確認すること
クライアントから始めてブロードキャストを取得し、ASA が自身のアドレスを giaddr としてリレーしたことを確認します。遠隔側では、サーバーがその要求を見て支店に合うスコープを選んだことを確認します。支店に戻り、クライアントがオファーを受け入れてゲートウェイに到達できることを確認します。
どの段階かが沈黙しているなら、リレーの記述をさらに足すのではなく、対応するポリシーやルートを確認します。誰かがエスカレーションする頃にはリレーの設定はたいてい正しく、変わったのはトンネルポリシーか戻り経路です。
三つの段階を変更記録に書きます。クライアント側インターフェース、リレー通信を覆う VPN ポリシー、サーバーから giaddr への戻り経路です。この記録があるからこそ、次の支店構築はデバッグ作業ではなく再現可能な作業になります。次のエンジニアが最初にどのコマンド出力を集めるべきかも、この記録が示します。