ASA VPN hairpin：一つのインターフェースで二つのトンネルをルーティングする

リモートユーザーが ASA に接続し、拠点の奥にあるホストを要求すると、ASA はその要求を、ユーザーが入ってきたのと同じインターフェースから送り出します。そのために二つ目の物理ポートは要りません。必要なのは、人が一つにまとめてしまいがちな四つの独立した判断です。hairpin を許可すること、正しいアドレスを保護するトンネル、約束した送信元を保つ NAT ポリシー、そしてサービスを認可するアクセスポリシーです。

一つのパケット、二つのトンネル

流れを追えば、処理の順序は謎ではなくなります。パケットはリモートアクセスのトンネルに入って到着し、復号されて、クライアントプールを送信元とする普通の IP パケットになります。次に ASA がそれをルーティングし、拠点間の crypto ACL と照合し、もう一度暗号化して、外側のインターフェースから拠点へ向けて送ります。

以下のアドレスは例示ですが、形が重要です。送信元はプールであり、ASA の内部 LAN ではありません。

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

そこから二つのことが導かれます。クライアントはリモートアクセス接続を通じて拠点のプレフィックスへの経路を必要とするため、split-tunnel か配布される経路一覧にそれを含める必要があります。そして拠点は、10.77.0.20 へ、あるいは NAT 設計が置き換えたアドレスへ、どうやって通信を戻すかを知っていなければなりません。

hairpin の許可は全体設定である

人が手を伸ばすコマンドは same-security-traffic permit intra-interface です。これにより通信は同じインターフェースに入って出ることができ、この経路が必要としているのはまさにそれです。同時に全体設定でもあります。有効にすると、同じインターフェースを二度通過する他のフローの挙動も変わります。

だからこれはデバッグの場ではなく、変更記録に属します。この装置のほかに、同じインターフェースを通る経路を取り得るものは何か、またそれを取るべきものがあるかを問い合わせてください。ゲストネットワークや重なり合うパートナー用トンネルがあるにぎやかな境界では、答えは自動的に「いいえ」ではありません。設定の横に理由を書き残してください。次のエンジニアが見つけるのはコマンドであって、会話ではないからです。

保護範囲と NAT は別物である

拠点間トンネルは、その crypto ACL が選ぶものを保護します。その ACL が ASA の内部サブネットを送信元として指定していると、リモートアクセスのプールは保護されず、パケットは不一致の通信に対するプラットフォームの挙動に応じて、破棄されるか平文で送られます。設計がプールのアドレスを保つ場合は、プールを保護対象のフローに加えてください。

次に NAT が、プールのアドレスが残るかどうかを決めます。Identity NAT ならそれは残り、拠点は 10.77.0.20 を送信元として見ます。変換は契約を変えます。拠点は変換後のアドレスへ通信を戻すようになり、拠点自身のポリシーがそれを受け入れる必要があります。規則の順序によって、crypto ACL が変換の前と後のどちらで一致するかが決まるので、どちらが勝つかを仮定せず、実際のフローを読んでください。

一つの通過の事例を動かすために、インターネット向けの一般的な PAT 規則を削除しないでください。的を絞った除外や意図的な identity 規則のほうが、外向きポリシーに穴を開けるより説明も取り消しも容易です。

暗号化は認可ではない

動作するトンネルが証明するのは、二つのピアが鍵とセレクタで合意していることだけです。このユーザーがそのサービスに到達してよいかについては何も語りません。リモートアクセス接続に付いた VPN フィルタやグループポリシーは、依然として拠点の宛先とポートを許可しなければならず、外側の経路のインターフェース ACL も依然として適用されます。

答えは両方向で試してください。隣のサービスは失敗すべきなのに接続が成功する、という結果は、一度の ping 成功より多くの情報を与えます。ポリシーが全開ではなく選択的であることを示すからです。拒否されるべき試験が成功したなら、責めるべきはトンネルではなくポリシーです。どちらの結果も変更記録に残し、次に担当する人がどちらの挙動が意図だったのか分かるようにしてください。

hairpin か、二つ目のインターフェースか

hairpin の通過は設計を小さく保ち、全体設定一つで済みます。別のインターフェース、あるいは独自の仮想インターフェースを持つ経路ベースのトンネルは、通過経路を分離し、インターフェースごとのポリシーを与えますが、アドレッシングと、もう一つの crypto map またはプロファイルのコストがかかります。どちらがより正しいということはなく、失敗の仕方が異なります。

経路ベースの設計は別の配置であり、同じ設定のチェックボックスではありません。そちらへ移ると、上で述べたポリシーベースの crypto ACL の議論は当てはまらなくなり、経路表が選択の仕事を始めます。

実際のクライアントから検証する

ASA から起動した検査は送信元アドレスが異なり、プールから拠点への経路をたどりません。五つの組の確認には packet-tracer を使い、そのうえで実際のリモートクライアントから本物の接続を開いてください。トレーサは模擬するだけで、クライアント自身のルーティングとポリシーを置き換えるものではないからです。

計画的な変更のあとは、動作すべきサービスに接続し、次に拒否されるべきサービスに接続し、そのうえで拠点の戻り経路を確認します。Cisco の VPN hairpin NAT の例は、intra-interface の許可、NAT、ACL を目に見える形で分けて保っており、それがまねる価値のある思考モデルです。