ASA hairpin：インターネット出口か、サイト間 VPN の経路か

同じ ASA の背後にいる二人のリモートアクセス利用者が、同じ outside インターフェースから通信を送っても、まったく別の扱いを受けることがあります。一方は公開ウェブサイトへ向かうので、パケットには送信元変換とインターネットルートが必要です。もう一方は同じインターフェースで終端するサイト間トンネルの先にあるサーバーへ向かうので、パケットには同一性、一致するトンネルセレクタ、クライアントプールへの戻り経路が必要です。同一インターフェースの許可は両方の前提条件であり、どちらの解決策でもありません。

二つの経路、一つのインターフェース

NAT ルールを書く前に、どちらの経路を作るのか決めてください。ルールは互換ではありません。経路 A はクライアントからインターネットへ向かいます。プールのアドレスが入り、変換された公開アドレスで出て、同じインターフェースを通って戻ります。経路 B はクライアントから別の IPsec ピアの向こう側にあるプライベートプレフィックスへ向かいます。プールのアドレスは保持され、再暗号化され、プールに応答する方法を知っているピアへ届けられます。

どちらにもまず必要なのは同一インターフェースの許可です。これがないと ASA は、パケットが到着したインターフェースからそのパケットを転送することを拒否し、障害はポリシーの問題ではなくルーティングの問題のように見えます。

same-security-traffic permit intra-interface

この一行が転送の構成を許可します。次の資料が説明しているとおりです。 ASA の NAT リファレンス 同一インターフェースの経路について述べています。クライアントルートを追加するわけでも、リソースを許可するわけでも、アドレスを変換するわけでも、IPsec セレクタを折衝するわけでもないので、この後にさらに三つか四つ追加するものだと考え、これが通ったことを進捗と読まないでください。

経路 A：クライアントがインターネットを求める場合

インターネット出口では、パケットが装置を出る前にプールのアドレスがプライベートでなくなっている必要があります。通常の PAT 設計では、ルールがプールを outside インターフェースのアドレスへ変換し、戻りの状態がクライアント向きのフローを復元します。

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

次に、クライアントが実際にその通信を ASA に運ぶよう要求したことを確認します。スプリットトンネルの除外では、公開宛先が電話自体の接続を通るため ASA にはまったく届かず、送られなかったパケットを NAT ルールで直すことはできません。グループポリシーのスプリットトンネル一覧と、テストしている宛先を突き合わせてください。

経路の残りは普通です。outside インターフェースからの使用可能なデフォルトまたは特定ルート、フローを許可するアクセス ポリシー、選んだリゾルバ ポリシーに従って扱われる DNS です。ここに route-lookup を、下記と同じ理由で追加してください。入口と出口のインターフェースが同一だからです。

経路 B：クライアントがプライベートサイトを求める場合

この経路は失敗する箇所が多いので、順番に書いてください。まずクライアントルートです。宛先プレフィックスがスプリットトンネル一覧にないと、クライアントはそれをトンネルに入れません。次にトンネルセレクタです。サイト間の暗号 ACL は、ローカル LAN からリモートプレフィックスだけでなく、プールのアドレスからリモートプレフィックスまでを覆う必要があります。最後に同一性です。通過するときにプールのアドレスがインターネット PAT へ変換されないようにします。

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

遠い側は、人がテストを忘れる部分です。ピアにはプールへの戻りルートと、それを含むセレクタが必要であり、 ピア自身のポリシーが、ピアが見る送信元アドレスを許可している必要があります。サイトを代わりに変換後の見え方で使う場合、それは有効な設計ですが、その場合は両方のピア、両方のセレクタ、両方のルーティングテーブルが変換後のアドレスで一致していなければなりません。

ルールの順序も確認してください。同一性ルールより上にある広い PAT ルールは、同一性ルールが評価される前にプライベートなやり取りを変換してしまい、症状は NAT エラーではなく、一致する SA のないサイトトンネルになります。

どちらの経路を作ったかを教えてくれるテスト

設定を読んで期待するのではなく、ASA 自身のパス評価を使ってください。 packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed は一つのフローの NAT 判断、ルート、ACL の結果を示します。プライベートな宛先で繰り返してください。NAT フェーズがプライベート間のフローを書き換えるなら、経路 B が必要なパケットに対して経路 A を作ったことになります。

さらに二つのコマンドが隙間を埋めます。 show nat detail は packet-tracer がたどったルール順を出力し、 show crypto ipsec sa は期待する組に対するセレクタが存在するかどうかを示します。SA がないのはセレクタかピアの設定の問題であり、NAT ルールで直せるものではありません。

各経路を、それが提供する通信で検証する

経路 A はクライアントからの通常の公開要求で、経路 B は実際に存在するプライベートリソースへの要求で受け入れてください。そのうえでそれぞれを拒否されるリソースで繰り返します。「許可されている」と「アクセス ポリシーで許可されている」は同じ証拠ではなく、ハブ発の ping はどちらのクライアント経路も試しません。

チケットでは二つのテスト記録を分けてください。送信元アドレス、宛先、一致した NAT ルール、結果です。次の報告が「VPN が壊れた」と言ったとき、その組があれば一分でどちらの経路が後退したか分かります。答えはたいていルートかセレクタであり、誰もが最初に疑う同一インターフェースの一行ではありません。