当社では、Azure VPN Gateway と、それぞれのクライアントの拠点にあるさまざまなオンプレミス ネットワーク アプライアンスを使用して、サイト間 VPN 接続を行っています。新しい接続をオンボードしようとしていますが、相手側のネットワークと IP 範囲が競合しています。以下の図は、クライアント側の詳細をすべて把握しているわけではないため、クライアント側での解釈は緩いものの、おそらく最もよく説明されていると思いますが、事実は次のとおりです。
Azure VPN S2S トンネルの両端で IP 範囲が競合しています
- ネットワーク A (192.168.1.0/24) は Azure VPN Gateway の背後にあり、当社が管理します。
- ネットワーク B (192.168.2.0/24) は、ネットワーク A から発信されるパケットのターゲット ネットワークであり、クライアントの責任であり、プライベート クラウドでホストされています。
- ネットワーク C (192.168.1.0/24) は、プライベート クラウド内の別のネットワークであり、クライアントのプライベート クラウド内で IP 範囲の競合が発生していることを除いて、トラフィックには関係ありません。
Azure サポートは、競合する範囲は現時点ではサポートされていないため、唯一の解決策は競合するネットワークの 1 つを再 IP することであると示しています。彼らによると、NAT はトンネルのどちらの側でも実行可能なソリューションではありません。Azure VPN Gateway の背後に新しいサブネットを追加し、トラフィックをネットワーク A に転送/NAT することもサポートされていません。
ネットワーク A の IP 再設定の影響により、IP 再設定はしたくありません。当然のことながら、クライアントはネットワーク C の IP 再設定もしたくありません。私が否定しているだけかもしれませんが、このシナリオに遭遇して、うまく回避したり解決したりした人は他にいますか?それなし再 IP 化ですか? もしそうなら、ソリューションをサポートする参照可能なドキュメントや構成があれば大変助かります。
ご協力いただければ幸いです。
答え1
- 特定のルーティング
競合しない A と B のネットワーク間のルーティングに興味があると書かれています... SonicWall がこの「内部クライアント ネットワーク」間でルーティングを行っており、ネットワーク C 上の特定の IP を使用しない場合は、192.168.1.0/24 全体ではなく、/32 などの特定の IP に対してネットワークを介したルーティングを行うことができます。ルーティングの決定では、「より一致したものが優先されます」。その場合、特定のトラフィックは B から A に正しくルーティングされ、残りはネットワーク C に渡されます...
VPN の種類によっては、SonicWall での構成が簡単になったり難しくなったりする可能性があります (可能な場合)。ただし、技術的には NAT なしで構成できる可能性があります。最悪の場合、Azure への VPN を終了させるデバイスを追加し、SonicWall にこれらの IP をこの追加ノードに誘導する静的ルート ルールを設定できます。
この方法では、Azure 側は C からアクセスできなくなりますが、記述内容に基づくと問題にはなりません。
- NAT
おっしゃるとおり、Azure VPN GW ではこの機能は提供されていないため、唯一の選択肢はトンネルの反対側 (SonicWall アプライアンス) でこれを行うことです。B 側、C 側からは、使用されていない IP 範囲 (例: 172.16.0.0/24) などの「リモート」サイトをアドレス指定でき、SonicWall に到達すると VPN にルーティングされ、ノードを離れる前に 192.168.1.0/24 に dNAT またはマッピングされます (最後のオクテット値を保持するか、必要なすべての IP をリストする 1:1 マッピングを実行します)。このように、VPN トラフィックの場合、Azure 側のリモート IP は「適切な」192.168.0.0/24 になり、Azure 側は NAT について何も知りません。
何らかの理由で SonicWall でこれを実行できない場合は、これを実行できる別のデバイスを独自の管理下に置き、VPN トンネルを終了し、ローカル ネットワークから 172.16.0.0/24 トラフィックの宛先 (ローカル ルーター上のルート) にすることができます。
問題となるのは、192.168.1.0/24 アドレスで応答する DNS と、識別に IP を使用する証明書を使用している場合だけです。DNS の場合、クライアントが「正しい」エンドポイントに接続できるように、「更新された」値を持つローカル DNS ゾーンが必要です。