ローカルネットワークのサブネットアドレスがリモートネットワークと競合する場合、VPNを介してリモートサーバーに接続する


35

これは、VPNクライアントのローカルネットワークと、そこからのVPNリンクを介したローカルネットワークとの間のIPv4サブネットの競合を解決するための標準的な質問です。

OpenVPNを介してリモートロケーションに接続した後、クライアントは、192.0.2.0 / 24などのサブネット上に存在するネットワーク上のサーバーにアクセスしようとします。ただし、クライアントのLAN上のネットワークには、同じサブネットアドレス192.0.2.0/24が含まれることがあります。この競合のため、クライアントはIPを入力してリモートサーバーに接続できません。VPNに接続している間は、パブリックインターネットにアクセスすることさえできません。

問題は、このサブネット192.0.2.0/24をVPNでルーティングする必要があるが、クライアントのLANとしてルーティングする必要があることです。

誰もがこの問題を軽減する方法を知っていますか?OpenVPNサーバーにアクセスできます。


3
到達しようとしているホストの/ 32アドレスに静的ルートを設定し、ゲートウェイとしてVPNピアを使用して、何が起こるかを確認できます。
SpacemanSpiff

VPNコンセントレータがクライアントルートを尊重する場合、境界セキュリティに何らかの支援が必要になる場合があります。会計LANにアクセスし、エンジニアリング範囲にルートを追加すると、問題なく接続できます。sonicwallのようなくだらないファイアウォールがこれを行う
-nandoP

@SpacemanSpiff:これによりクライアント側の問題解決できますが、VPNクライアントからではなく独自のネットワークからの接続であると見なされるため、サーバーは応答できません。
マッシモ

回答:


18

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トンネルの構成

したがって、実際の実装は、多くの要因、関連するオペレーティングシステム、関連するソフトウェア、およびその可能性に大きく依存します。しかし、それは確かに実行可能です。少し考えて実験する必要があります。

リンクからわかるように、私はこれをシスコから学びました。


NATは多くのVPN接続とその変換でも機能しますか?私はここで事件を完全に理解していませんでした。私はここにunix.stackexchange.com/q/284696/16920のスレッドがあります。Unix -Wayの重複サブネットでサイト間VPNを行う方法
レオレオポルドヘルツ

17

単一または少数の既知のサーバーIPに対する一時的なダーティな回避策が必要な場合、最も簡単な解決策は静的クライアント側ルーティングオプションです。

私の場合、希望する宛先サーバー(192.168.1.100)をLinuxクライアントのルーティングテーブルに追加しました:

route add 192.168.1.100 dev tun0

その後、route deleteコマンドを使用してこの静的ルートを削除します。


2
これは完璧なソリューションであり、さらに完璧なタイミングです!:)
ユヴァルA

これはどれくらい持続しますか?切断するまで?再起動するまで?
カルボカチオン

1
私のLinuxシステム(ubuntu / mintを使用したxfce)では、vpnが切断された後、はい、再起動後も設定は「失われます」。routeコマンドで設定がアクティブかどうかを確認できます(通常、下部にipとtun0デバイスを持つエントリがあります)
Aydin K.

OSXバージョンのルートでは、インターフェイスの取り方が異なるため、dev tun0必要ではなく-interface tun0
サイレン

5

うん、これは最悪です。私にとっては、VPNの管理者がより不明瞭なIP範囲を使用する必要があることに気付く前に、ホテルの部屋からずっと発生していました。10.0.0.0/24と10.1.1.1/24が最悪です。あなたがそれを助けることができるなら、そのようなワイヤレスネットワークを決してIPしないでください。

したがって、答えは、別の内部ネットワーク(10.255.255.0/24)を使用するようにwapを「修正」し、次にdiffリース(つまり、corp vpnにルーティングできる範囲内のip)を与えるか、または/ wapで管理者を取得できません。スターバックスに移動してください。または20分間のウォードライビング:)

これがラボ設定にある場合は、異なる範囲を使用してください。


ほんとに?より良いオプションはありませんか?
ジョンラッセル

1
私が知っていることではない....これは常に問題でした...誰かが私の答えを下票したように見えますが、実際には解決策を提案しませんでした....メッセンジャーを殺します!
nandoP

3

El Capitanを実行しているMacを使用しています。上記の提案は私には役に立たなかったが、彼らは私を実用的な解決策に導いた:

  1. VPNを開始する前に、実行します ifconfig
  2. VPNを起動しifconfig、新しいインターフェースであることに注意してください。私の場合、それは192.168.42.74の IPアドレスを持つppp0でした

    ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00
    
  3. 入力する:

    sudo route add 192.168.1.79  192.168.42.74
    

最初にaでテストし、ping次にgitサーバーにアクセスして動作することを証明しました。

上記のようにrouteコマンドの最後にdev ppp0を使用しようとすると、文句を言いました。


2
192.168.1.79この取引所には何がありますか?
カルボカチオン

接続先の宛先サーバー。このサーバーは、ローカル接続ではなく、VPNと同じネットワークに存在します。
カルロデルムンド

1

競合するIP範囲(10.x)がある共同作業スペースで使用しているシンプルなソリューションがあります

携帯電話でネットワークに接続した後、Bluetooth経由でラップトップとネットワーク接続を共有しました。これで、リモートの雇用主にVPNを使用できます。

より高速な接続が必要な場合、これはUSB経由でも同じように機能すると確信しています。


1
ねえ、それは実際にはかなり賢い解決策です。
ネイサンオスマン

1

数個の1つまたは2つのIPアドレスをヒットする必要がある場合、次のようにovpn構成ファイルにrouteステートメントを追加します。

ルート192.168.1.10 255.255.255.255

ルート192.168.1.11 255.255.255.255

VPNを接続すると、それらのIPだけのルートが追加され、VPNが切断されたときに削除されます。

とにかくWindowsで働いていました。


1

Aydin K.からの回答はLinux向けです。Windowsで同じ機能が必要な場合は、次のように入力できます。

route ADD 192.168.1.10 <IP of tunnel adapter>

または

route ADD 192.168.1.10 IF <interface id>

次のコマンドでインターフェイスIDを取得できます。

route print

0

念のため、この問題全体は、長年のIPv4アドレス不足と、この不足を回避するためにNATの背後にあるプライベートIP範囲を広範に使用したことによるものです!

この問題に対する理想的かつ決定的な解決策は非常に簡単です(グローバルに展開するには時間がかかりますが、時間がかかりますが):IPv6 ...

IPv6の世界では、パブリックIPが不足することはありません(数十年でイベントは発生しません)。したがって、すべてのネットワークのすべてのデバイスにパブリックIPを持たない理由はありません。ネットワークの分離が必要な場合は、ファイアウォールでフィルタリングを続けますが、NATいNATは使用しません...

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.