ローカルネットワークのサブネットアドレスがリモートネットワークと競合する場合のVPNを介したリモートサーバーへの接続
これは 標準的な質問 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サーバーにアクセスできます。
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をラップトップに実装する必要があります。
- オフィスゲートウェイには、両方のシナリオをカバーするために、NAT-freeとNATedの2つのVPNが必要です。そうでない場合、NATメソッドで選択したサブネットの1つを誰かが選択した場合、機能しません。
VPNクライアントによっては、ローカルセグメントのネットワークアドレスに応じて、自動的に一方のVPNを選択できる場合があります。
このコンテキストでのNATの言及はすべて、いわばトンネルパースペクティブ内で行われるNAT関数を示していることに注意してください。プロセスごとに、静的NATマッピングは、パケットがトンネルに入る前、つまり、インターネットを介して他のVPNゲートウェイに転送されるトランスポートパケットにカプセル化される前に行う必要があります。
これは、VPNゲートウェイのパブリックIPアドレス（実際にはNAT：である可能性がありますが、VPNを介したリモートサイトへのトランスポートの観点からは完全に外れています）を、マスカレードとして使用される一意のプライベートアドレスと混同しないことを意味します。重複するプライベートアドレス。この抽象化を描くのが難しい場合は、この目的でNATをVPNゲートウェイから物理的に分離する方法を以下に示します。
重複するネットワークでのNATの使用 。
NATとVPNゲートウェイの両方の機能を実行できる1台のマシン内の論理的な分離に同じ図を凝縮することは、同じ例をさらに1歩進めるだけですが、手元のソフトウェアの機能をより重視します。 。たとえば、OpenVPNやiptablesと組み合わせてハッキングし、ここにソリューションを投稿することは、価値のある挑戦です。
ソフトウェア的には確かに可能です：
PIX/ASA 7.x以降：重複するネットワーク構成例を持つLAN-to-LAN IPsec VPN
そして：
LANサブネットが重複しているルーター間のIPSecトンネルの構成
したがって、実際の実装は、多くの要因、関連するオペレーティングシステム、関連するソフトウェア、およびその可能性に依存します。しかし、それは確かに実行可能です。少し考えて実験する必要があります。
リンクからわかるように、シスコからこれを学びました。
単一または少数の既知のサーバーIPに対する一時的なダーティ回避策が必要な場合、最も簡単な解決策は、静的なクライアント側のルーティングオプションです。
私の場合、目的の宛先サーバー（192.168.1.100）をLinuxクライアントのルーティングテーブルに追加しました。
route add 192.168.1.100 dev tun0
その後、route deleteコマンドでこの静的ルートを削除します。
うん、これは最悪です。私にとって、それはホテルの部屋からいつでも起こりました。VPN管理者が、あいまいなIP範囲を使用する必要があることに気づく前に。 10.0.0.0/24と10.1.1.1/24が最悪です。あなたがそれを助けることができるなら、そのような無線ネットワークを決してipしないでください。
したがって、答えは、異なる内部ネットワーク（つまり10.255.255.0/24）を使用するようにwapを "修正"してから、差分リース（つまり、corp vpnにルーティングできる範囲のIP）を与えるか、または/ wapで管理者を取得できません。スターバックスにアクセスしてください。または20分のワードライビング:)
これがラボ環境にある場合は、別の範囲を使用してください。
El Capitanを実行しているMacを使用しています。上記の提案は私にとってはうまくいきませんでしたが、彼らは私を実用的な解決策に導きました：
- vPNを開始する前に、
ifconfigを実行します vPNを開始し、
ifconfigを実行して、どちらが新しいインターフェースであるかをメモします。私の場合、それはpppで、IPアドレスは192.168.42.74でした。ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00入力：
Sudo route add 192.168.1.79 192.168.42.74
最初にpingを使用してテストし、次にgitサーバーにアクセスすることで機能することを証明しました。
上記のようにrouteコマンドの最後にdev pppを使用しようとすると、文句を言われました。
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
競合するIP範囲（10.x）があるコワーキングスペースで使用している簡単なソリューションがあります
携帯電話でネットワークに接続し、Bluetooth経由でネットワーク接続をラップトップと共有しました。これで、リモートの雇用主にVPNを使用できます。
より高速な接続が必要な場合、これはUSB経由でもまったく同じように機能します。
1つまたは2つのIPアドレスをヒットするだけの場合は、次のように、ovpn構成ファイルにrouteステートメントを追加します。
ルート192.168.1.10 255.255.255.255
ルート192.168.1.11 255.255.255.255
それはあなたがあなたのVPNを接続したときにそれらのIPだけのためのルートを追加し、それがそれが切断したときにそれを削除します。
とにかくWindowsで私のために働いた。
思い出させてください：この問題全体は、長年にわたるIPv4アドレスの不足と、この不足を回避するための プライベートIP範囲 の広範な使用によるものですNAT！
この問題の理想的で決定的な解決策は、非常に簡単です（グローバルに展開できるようになるまでには時間がかかります）： IPv6 ...
IPv6の世界では、パブリックIPの不足はありません（数年後には発生しません）。したがって、すべてのネットワークのすべてのデバイスでパブリックIPを使用しない理由はありません。また、ネットワークの分離が必要な場合は、ファイアウォールでフィルタリングを続けますが、醜いNATは使用しません...