ASA サイト間 VPN 経由で内部サービスを公開する

サイト間 VPN の背後にあるサービスを公開するのは、五つの失敗点を持つ一つの作業であり、それらは決まった順序で失敗する。トンネルが上がり、変換が一致し、支店が応答し、応答が同じ経路で戻ってくる。どれか一つでも誤っていれば、ブラウザには同じことが表示される：接続がハングするかリセットされるだけだ。リストを上から順にたどり、最初に失敗した確認で止める。

確認 1: トンネルが送信元アドレスを保護している

すでにトラフィックが通っているトンネルから始め、公開する予定のアドレスが保護範囲の内側にあることを確認する。ASA ではその範囲は暗号 ACL か VTI のルートから決まり、支店が管理用に使うサブネットではなく、送信元の実際のアドレスを覆っていなければならない。送信元を外すセレクタでは、トンネルは上がっていてもフローが決して入らない。

変換に触れる前に、トンネルのカウンタとルートテーブルで確認する。ハブからトンネル越しに送信元へ到達できなければ、このリストの後半では修復できない。

保護範囲と送信元アドレスが一致しない場合はここで止める。

確認 2: 支店がどの送信元を見るかを決める

支店は元のクライアントアドレスを見るか、変換後のアドレスを見るかであり、その選択が戻り経路を決める。クライアントアドレスを保持すると送信元のログはきれいに読めるが、その場合、支店は公開クライアント向けの応答をトンネル経由で返さなければならず、通常のインターネットのデフォルト経路は逆方向に送ってしまい、接続は片方向で死ぬ。送信元を、支店がすでにトンネル経由でルーティングしているアドレスに変換すれば、その要件は消える。

変換は、送信元が記録できる内容と、送信元ベースのルールが一致できる範囲も変える。アプリケーションがリクエストの背後にいる人を知る必要があるなら、それは認証付きリバースプロキシの役割であり、NAT の判断ではない。

確認 3: 実際のインターフェースに合わせて変換を書く

ASA は変換ルールを順に評価し、どれが一致したかを報告するので、ルール内のインターフェースの組は飾りではない。外から内への経路向けに書かれたルールは、想定した入口と出口が異なるフローには一致しない。

これから作る経路には四つの区間があり、四つすべてが一致しなければならない：

この表の範囲はプレースホルダーとして扱う。重要なのは、変換後のタプルが支店にとってトンネル越しに受け入れられるアドレスであること、そして NAT 状態に逆マッピングが存在し、出ていくときに応答が復元されることだ。

確認 4: アクセスルールを公開ポートに絞る

ホストではなくポートを公開する。すべてのサービスで送信元を許可するルールは、公開した一つのアプリケーションを、送信元が動かすすべてへの経路に変えてしまい、わざとインターネットに出さなかった管理インターフェースも含まれる。変換後の送信元から送信元へ、公開ポートだけを許可し、管理サービスは VPN 専用の経路に残す。

同時にルールの順序も確認する。具体的なルールの上に広い許可があると、具体的なルールは見えなくなる。

確認 5: 一つのリクエストとその応答を追跡する

ブラウザから始めない、ブラウザはどの区間が失敗したかを隠すからだ。ハブでフローを追跡し、何かを変える前に結果を読む。

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

トレースは、一致した変換、フローを許可または拒否したアクセスルール、パケットがトンネルにルーティングされたかどうかを示す。想定していないインターフェースから出ていると示すなら、NAT ルールのインターフェースの組が誤っている。拒否と示すなら、ルールの順序が誤っている。トンネルには届くが送信元が決して応答しないなら、問題は支店の戻り経路だ。

次に外から実際のリクエストを一つ送り、応答が同じトンネルで戻ることを確認する。公開したエントリ、変換、保護されたアドレスの組、戻りルートを公開記録として残す。