Anypoint VPN か Transit Gateway NAT：翻訳はどこで行うか
Anypoint VPN 自体はアドレスを変換しません。NAT を約束する前に、ファイアウォールでの PAT、AWS のプレフィックスマップ、別のアタッチメントのどれを選ぶかを決めます。
NAT の要件は、どのアドレスが変わり、どのコンポーネントにその変更が許されるのかを名指しするまでは要件になりません。MuleSoft の接続では、この判断に入力が三つあります。バックエンドが多対一のポート変換を必要とするのか、一対一のプレフィックス別名を必要とするのか。実際に所有している AWS のアタッチメントがそのマッピングを実行できるのか。そして経路全体がベンダーのサポートする組み合わせに収まるのか。ここを間違えると、動作するがレビューで落ちるラボを作ることになります。
唯一の固定点は、Anypoint VPN 自体が変換装置ではないということです。CloudHub 2.0 のドキュメントは NAT をそこでは未サポートとして挙げており、トンネルがワーカーのアドレスを隠してくれると前提する設計はすでに破綻しています。
変換に何をさせるかを決める
多くのアプリケーションワーカーがバックエンドから一つのアドレスに見える必要があるなら、要件は共有の送信元変換であり、通常は自分で管理するファイアウォール上のステートフルな SNAT か PAT です。その要素は承認された経路上に置かれ、フローの寿命のあいだ状態を保持し、書き換えたすべての接続の戻りトラフィックを見る必要があります。セッションの途中で状態を失うと接続は劣化ではなく終了します。変換状態の共有を拒むファイアウォールのペアは、フェイルオーバー後に待機側のメンバーに着地したセッションをすべて落とします。その要素はスループットではなく同時フロー数でサイズを決めてください。
逆に二つのネットワークが重複し、各ホストに別々の別名が必要なら、要件は曖昧さのないマップ済みプレフィックス、一致するルート、マッピングと整合する名前解決を備えた一対一のアドレス計画です。すべてのワーカーを一つのアドレスの背後に隠すことはその安価な版ではなく、設計レビューで一方を他方に取り替えることがプロジェクトが四半期を失う理由です。
製品を選ぶ前に、判断を具体的な言葉で記録してください。元の送信元、元の宛先、変換後の値、開始方向、変換装置の所有者、想定される応答経路です。バックエンドのログがどの識別情報を保持するかも加えてください。すべての送信元を隠す設計はクライアントごとの監査も破壊します。
AWS がマッピングを代行できるか確認する
AWS は現在、Transit Gateway と Cloud WAN のアタッチメント上で管理された一対一 NAT を文書化しており、これは 2026 年の十月下旬に発表されたため、トランジットゲートウェイは決して変換できないという従来の一般論は古くなっています。Transit Gateway NAT のドキュメントはステートレスな IPv4 プレフィックスのマッピングを説明しています。元のプレフィックスと変換後のプレフィックスは同じ長さを保ち、ホストビットとトランスポートポートは変換を経ても残ります。イングレスとエグレスの方向は別々の設計判断として読んでください。別々に設定され、片方が準備できていても他方はそうでないことがあります。その説明のどこにもフロー単位の状態は示されていないので、マッピングが接続を追跡してくれると期待しないでください。
つまり 10.80.0.0/16 を 172.28.0.0/16 にマップすると、10.80.10.23 は 172.28.10.23 になります。これは /16 を一つのアドレスに畳み込むものではなく、PAT の要件を置き換えるものでもありません。選択されたアタッチメント種別も対象で、VPC や Site-to-Site VPN が含まれますが Client VPN のアタッチメントは含まれず、設定は Anypoint 側ではなくトランジットゲートウェイの所有者の下にあります。
この機能はもう一つの制御点として扱い、導入がそれを使える証明とは考えないでください。CloudHub 2.0 は顧客自身の AWS アカウント内のトランジットゲートウェイへのプライベートスペースのアタッチメントを、リージョン条件と権利条件付きで文書化しています。新しい選択肢を前提に設計する前に、実際のアタッチメント種別、その所有者、ベンダーのサポート姿勢を確認してください。
経路をサポートされる境界の内側に保つ
ファイアウォールの変換装置では、動作中のトンネルに汎用の NAT ルールを貼るのではなく、その製品がサポートする VPN、変換、ルーティングのモデルを使ってください。バックエンドの応答は同じ変換要素を通って戻る必要があり、健全なアウトバウンドトンネルはその戻り経路について何も語りません。
トランジットゲートウェイの経路では、プライベートスペースのアタッチメント、関連するルートテーブル、オンプレミスのアタッチメント、そして顧客が実際に設定できる部分を棚卸ししてください。これは別の接続アーキテクチャであり、既存の Anypoint VPN 接続に NAT のチェックボックスを後付けするものではなく、サポート境界もそれとともに動きます。
三つの選択肢を一つの表で比較する
ほとんどのチームは二つの問いに答えるだけで十分です。多対一か一対一か、そしてアタッチメントを誰が所有するか。下の表はその答えを出発点の選択肢に変えます。
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
三列目は後付けの考えではなく、レビューの問いとして読んでください。紙の上では許されていても、所有していないアタッチメントに設定されたプレフィックスマップは依然として行き詰まったプロジェクトであり、トラフィックは通すがクライアントごとのログを壊す PAT ルールは、その後に続く監査で落ちます。
約束する前にマッピングを検証する
新しいアプリケーション操作を一つ経路に流し、要求だけでなく応答も確認してください。バックエンドの所有者にどの送信元アドレスがログに記録されたかを尋ね、アドレスファミリーの扱いが両方向で計画と一致するか確かめ、拒否されるべき経路が今も拒否されることを検証します。古い接続は、たった今変更したマッピングについて何も証明しません。
バックエンドの認証は、どの変換済みアドレスが許可リストを満たすかから独立させてください。マッピングはネットワークの配管であり、アクセス制御の判断ではないからです。パスワードリセットが NAT プレフィックスに依存した瞬間、今後のあらゆる範囲変更が障害になります。
承認の前に三つの答えを書き留めてください。変換の種類、変換装置の所有者、そしてそれを運ぶサポート済みのアタッチメントまたは製品経路です。どれか一つでも推測のままだと、その設計は変更ウィンドウに耐えません。