NATを使用してこれを解決することができます。あまりエレガントではありません。
したがって、実際には競合することのないほど珍しいネットワーク番号を持つ内部ネットを持つことでこれを解決することはできないという仮定の下で、ここに原則があります：
ローカルサブネットとリモートサブネットのネットワーク番号は同じであるため、クライアントからのトラフィックは、トンネルゲートウェイを経由して宛先に到達する必要があることに気付かないでしょう。そして、たとえそれが可能だと想像したとしても、状況はリモートホストにとっても答えを送信しようとしているのと同じです。
したがって、私と一緒にいて、今のところ、完全な接続のためにサイドの問題はありません、ホストを区別してルーティングを可能にするためにトンネル内で両端をNATする必要があると思います。
ここでいくつかのネットを作ります：
- あなたのオフィスネットワークは192.0.2.0/24を使用しています
- リモートオフィスは192.0.2.0/24を使用します
- オフィスネットワークVPNゲートウェイは、NATされたネットワーク番号198.51.100.0/24の後ろに192.0.2.0/24ホストを隠します
- リモートオフィスネットワークVPNゲートウェイは、NATされたネットワーク番号203.0.113.0/24の後ろに192.0.2.0/24ホストを隠します
したがって、VPNトンネル内では、オフィスのホストは198.51.100.xになり、リモートオフィスのホストは203.0.113.xになります。さらに、すべてのホストがそれぞれのVPNゲートウェイのNATで1：1にマッピングされているとしましょう。例：
- オフィスネットワークホスト192.0.2.5/24は、オフィスVPNゲートウェイNATで198.51.100.5/24として静的にマッピングされます
- リモートオフィスネットワークホスト192.0.2.5/24は、リモートオフィスVPNゲートウェイNATで203.0.113.5/24として静的にマッピングされます
そのため、リモートオフィスのホスト192.0.2.5/24がオフィスネットワーク内の同じIPでホストに接続する場合、宛先としてアドレス198.51.100.5/24を使用して接続する必要があります。次のことが起こります。
- リモートオフィスでは、ホスト198.51.100.5は、VPN経由で到達し、そこにルーティングされるリモート宛先です。
- リモートオフィスでは、パケットがNAT機能を通過するため、ホスト192.0.2.5は203.0.113.5としてマスカレードされます。
- オフィスでは、パケットがNAT機能を通過すると、ホスト198.51.100.5は192.0.2.5に変換されます。
- オフィスでは、ホスト203.0.113.5へのリターントラフィックは同じプロセスを逆方向に通過します。
そのため、解決策はありますが、これが実際に機能するためには多くの問題に対処する必要があります。
- リモート接続にはマスカレードIPを使用する必要があります。DNSは複雑になります。これは、接続ホストから見ると、エンドポイントには一意のIPアドレスが必要であるためです。
- NAT機能は、VPNソリューションの一部として両端で実装する必要があります。
- ホストを静的にマッピングすることは、相手からの到達可能性のために必須です。
- トラフィックが単方向の場合、受信側のみが関連するすべてのホストの静的マッピングを必要とします。必要に応じて、クライアントは動的にNAT処理されます。
- トラフィックが双方向の場合、両端では、関係するすべてのホストの静的マッピングが必要です。
- スプリットVPNまたは非スプリットVPNに関係なく、インターネット接続が損なわれてはなりません。
- 1対1にマッピングできない場合、面倒になります。注意深い簿記が必要です。
- 当然、NATアドレスを使用するリスクもありますが、これも重複していることが判明しました:-)
そのため、これを解決するには慎重な設計が必要です。リモートオフィスが実際に道路の戦士で構成されている場合、その中に問題の層を追加します。
- ネットIDの重複がいつになるかを事前に知ることはありません。
- リモートオフィスゲートウェイNATをラップトップに実装する必要があります。
- オフィスゲートウェイには、両方のシナリオをカバーするために、2つのVPN、1つはNATフリー、もう1つはNATが必要です。そうしないと、NATメソッド用に選択したサブネットのいずれかを誰かが選択した場合、動作しません。
VPNクライアントによっては、ローカルセグメントのネットワークアドレスに応じて、いずれかのVPNを自動的に選択できる場合があります。
このコンテキストでのNATのすべての言及は、いわばトンネルの観点内で行われるNAT機能を示していることに注意してください。プロセスごとに、静的NATマッピングは、パケットがトンネルに「入る」前、つまり、インターネットを介して他のVPNゲートウェイに到達するトランスポートパケットにカプセル化される前に行う必要があります。
これは、VPNゲートウェイのパブリックIPアドレス（および実際にはNAT：edでも、VPNを介したリモートサイトへのトランスポートの完全に外部）と、マスカレードとして使用される一意のプライベートアドレスを混同しないことを意味します重複するプライベートアドレスの場合。この抽象化を想像するのが難しい場合、この目的のために
NATを VPNゲートウェイから物理的に分離する方法の図を以下に示します。
NATとVPNゲートウェイの両方の機能を実行できる1台のマシン内の論理的な分離に同じ状況を要約することは、同じ例をさらに一歩進めただけですが、手元のソフトウェアの機能をより重視しています。OpenVPNやiptablesなどと一緒にハッキングして、ここにソリューションを投稿するのは、やりがいのある挑戦でしょう。
ソフトウェア的には確かに可能です：
PIX / ASA 7.x以降：重複したネットワークを使用したLAN-to-LAN IPsec VPNの構成例
および
重複したLANサブネットを持つルーター間のIPSecトンネルの構成
したがって、実際の実装は、多くの要因、関連するオペレーティングシステム、関連するソフトウェア、およびその可能性に大きく依存します。しかし、それは確かに実行可能です。少し考えて実験する必要があります。
リンクからわかるように、私はこれをシスコから学びました。