Frage Herstellen einer Verbindung mit einem Remote-Server über ein VPN, wenn die Subnetzadresse des lokalen Netzwerks mit einem Remote-Netzwerk in Konflikt steht


Das ist ein Kanonische Frage zum Lösen von IPv4-Subnetzkonflikten zwischen dem lokalen Netzwerk eines VPN-Clients und einem VPN-Link über das VPN-Netzwerk.

Nach dem Herstellen einer Verbindung zu einem Remote-Standort über OpenVPN versuchen Clients, auf einen Server in einem Netzwerk zuzugreifen, das in einem Subnetz wie 192.0.2.0/24 vorhanden ist. Manchmal hat das Netzwerk im LAN des Clients jedoch dieselbe Subnetzadresse: 192.0.2.0/24. Clients können aufgrund dieses Konflikts keine Verbindung zum Remote-Server herstellen, indem sie ihre IP-Adresse eingeben. Sie können nicht einmal auf das öffentliche Internet zugreifen, während sie mit dem VPN verbunden sind.

Das Problem besteht darin, dass dieses Subnetz 192.0.2.0/24 vom VPN geroutet werden muss, aber auch als LAN des Clients geroutet werden muss.

Kann jemand dieses Problem abschwächen? Ich habe Zugriff auf den OpenVPN-Server.


30
2017-10-26 23:21


Ursprung


Sie können versuchen, eine statische Route für die / 32-Adresse des Hosts festzulegen, den Sie erreichen möchten, und den VPN-Peer als Gateway zu verwenden und zu sehen, was passiert. - SpacemanSpiff
Wenn der VPN-Konzentrator Client-Routen berücksichtigt, benötigt Ihre Perimeter-Sicherheit möglicherweise Hilfe. Ich bekomme Zugriff auf Buchhaltung LAN, Route hinzufügen, um Engineering-Bereich, und ich kann dann kein Problem verbinden. beschissene Firewalls wie Sonicwall machen das - nandoP
@SpacemanSpiff: Währenddessen könnte Um das Problem auf der Client-Seite zu lösen, könnte der Server immer noch nicht antworten, da die Verbindung als aus dem eigenen Netzwerk kommend und nicht von einem VPN-Client kommend angesehen wird. - Massimo


Antworten:


Es ist möglich, dies mit NAT zu lösen; es ist einfach nicht sehr elegant.

Also unter der Annahme, dass Sie dies nicht lösen könnten, indem Sie interne Netze haben, die so ungewöhnliche Netzwerknummern haben, dass sie niemals in Konflikt geraten, hier ist das Prinzip:

Da sowohl das lokale als auch das entfernte Subnetz identische Netzwerknummern haben, wird der Verkehr von Ihrem Client niemals erkennen, dass er durch das Tunnel-Gateway gehen muss, um sein Ziel zu erreichen. Und selbst wenn wir es uns vorstellen könnten, wäre die Situation für den entfernten Host die gleiche, da es eine Antwort senden wird.

Bleiben Sie also bei mir und tun Sie so, als ob es noch keine Seitenthemen gibt, da ich schreibe, dass Sie für volle Konnektivität beide Enden von NAT innerhalb des Tunnels benötigen, um die Hosts zu unterscheiden und Routing zu ermöglichen.

Hier ein paar Netze machen:

  • Ihr Büronetzwerk verwendet 192.0.2.0/24
  • Ihr Remote-Office verwendet 192.0.2.0/24
  • Ihr Büronetzwerk-VPN-Gateway verbirgt 192.0.2.0/24 Hosts hinter der NAT-Netzwerknummer 198.51.100.0/24
  • Ihr Remote-Office-Netzwerk-VPN-Gateway verbirgt 192.0.2.0/24 Hosts hinter der NAT-Netzwerknummer 203.0.113.0/24

Innerhalb des VPN-Tunnels befinden sich nun die Office-Hosts 198.51.100.x und die Remote-Office-Hosts 203.0.113.x. Lassen Sie uns weiterhin so tun, als wären alle Hosts 1: 1 im NAT ihrer jeweiligen VPN-Gateways abgebildet. Ein Beispiel:

  • Ihr Büronetzwerk-Host 192.0.2.5/24 wird statisch als 198.51.100.5/24 im Office-VPN-Gateway-NAT zugeordnet
  • Ihr Remote-Office-Netzwerk-Host 192.0.2.5/24 wird statisch als 203.0.113.5/24 im Remote-Office-VPN-Gateway-NAT zugeordnet

Wenn der Host 192.0.2.5/24 im Remote-Office eine Verbindung zum Host mit der gleichen IP-Adresse im Büronetzwerk herstellen möchte, muss die Adresse 198.51.100.5/24 als Ziel verwendet werden. Folgendes passiert:

  • In der Remotebüro ist Host 198.51.100.5 ein Remoteziel, das über das VPN erreicht und dort weitergeleitet wird.
  • In der Remotebüro wird Host 192.0.2.5 als 203.0.113.5 maskiert, wie das Paket die NAT-Funktion übergibt.
  • Im Büro wird der Host 198.51.100.5 in 192.0.2.5 übersetzt, wenn das Paket die NAT-Funktion passiert.
  • Im Büro geht der Rückverkehr zum Host 203.0.113.5 den gleichen Prozess in umgekehrter Richtung durch.

Obwohl es eine Lösung gibt, gibt es eine Reihe von Problemen, die berücksichtigt werden müssen, damit dies in der Praxis funktioniert:

  • Die maskierte IP muss für Remote-Verbindungen verwendet werden. DNS wird komplex. Dies liegt daran, dass Endpunkte eine eindeutige IP-Adresse haben müssen, die vom verbindenden Host aus betrachtet wird.
  • Eine NAT-Funktion muss an beiden Enden als Teil der VPN-Lösung implementiert werden.
  • Die statische Zuordnung von Hosts ist ein Muss für die Erreichbarkeit vom anderen Ende.
  • Wenn der Datenverkehr unidirektional ist, benötigt nur das empfangende Ende eine statische Zuordnung aller beteiligten Hosts. Der Client kann, wenn es gewünscht wird, dynamisch NAT sein.
  • Wenn der Datenverkehr bidirektional ist, müssen beide Enden eine statische Zuordnung aller beteiligten Hosts durchführen.
  • Die Internetkonnektivität darf unabhängig von Split- oder Non-Split-VPN nicht beeinträchtigt werden.
  • Wenn Sie nicht 1-zu-1 zuordnen können, wird es unordentlich; sorgfältige Buchführung ist eine Notwendigkeit.
  • Natürlich läuft man Gefahr, NAT-Adressen zu verwenden, die sich auch als Duplikate herausstellen :-)

Um dies zu lösen, bedarf es eines sorgfältigen Designs. Wenn dein entferntes Büro wirklich aus Road Warriors besteht, fügst du eine Ebene von Problemen hinzu:

  • sie wissen es nie vorher, wenn sie auf überlappende Netz-IDs landen.
  • die NAT-Schnittstelle des Remote-Office-Gateways müsste auf ihren Laptops implementiert werden.
  • Das Office-Gateway würde zwei VPNs benötigen, ein NAT-freies und ein NAT-Netzwerk, um beide Szenarien abzudecken. Andernfalls, Falls jemand eines der Subnetze auswählen sollte, die Sie für die NAT-Methode ausgewählt haben, würden die Dinge nicht funktionieren.

Abhängig von Ihrem VPN-Client können Sie je nach der Netzwerkadresse des lokalen Segments automatisch ein VPN oder das andere auswählen.

Beachten Sie, dass alle Erwähnung von NAT in diesem Zusammenhang eine NAT-Funktion bezeichnet, die sozusagen innerhalb der Tunnelperspektive stattfindet. Prozessweise muss das statische NAT-Mapping durchgeführt werden, bevor das Paket in den Tunnel "eintritt", d. H. Bevor es in das Transportpaket eingekapselt wird, das es über das Internet zu dem anderen VPN-Gateway bringen soll.

Dies bedeutet, dass man die öffentlichen IP-Adressen der VPN-Gateways (die in der Praxis auch NAT sein können, aber dann völlig außerhalb der Perspektive des Transports zum entfernten Standort durch VPN sind) mit den eindeutigen privaten Adressen, die als Maskeraden verwendet werden, nicht verwechseln darf für die doppelten privaten Adressen. Wenn diese Abstraktion schwierig darzustellen ist, wird hier eine Abbildung gemacht, wie NAT physisch vom VPN-Gateway getrennt werden kann:
Verwenden von NAT in überlappenden Netzwerken.

Das gleiche Bild zu einer logischen Trennung innerhalb einer Maschine zu verschmelzen, die sowohl die NAT- als auch die VPN-Gateway-Funktionalität ausführen kann, führt dasselbe Beispiel noch einen Schritt weiter, legt jedoch mehr Wert auf die Fähigkeiten der vorliegenden Software. Es wäre eine würdige Herausforderung, es zusammen mit OpenVPN und iptables zu hacken und die Lösung hier zu veröffentlichen.

Softwareweise ist es sicherlich möglich:
PIX / ASA 7.x und höher: LAN-zu-LAN-IPsec-VPN mit Konfigurationsbeispiel für überlappende Netzwerke
und:
Konfigurieren eines IPSec-Tunnels zwischen Routern mit doppelten LAN-Subnetzen

Die tatsächliche Implementierung hängt daher von vielen Faktoren ab, den beteiligten Betriebssystemen, der zugehörigen Software und ihren Möglichkeiten nicht zuletzt. Aber es ist sicherlich machbar. Sie müssten ein wenig nachdenken und experimentieren.

Das habe ich von Cisco gelernt, wie es die Links zeigen.


18
2017-11-23 22:01



Könnte NAT auch mit vielen VPN-Verbindungen und deren Übersetzungen arbeiten? Ich habe den Fall hier nicht vollständig verstanden. Ich habe einen Thread hier unix.stackexchange.com/q/284696/16920 Über Wie Site-to-Site-VPN mit überlappenden Subnetzen Unix-Way? - Léo Léopold Hertz 준영


Wenn Sie einen temporären Dirty-Workaround für einen oder mehrere wenige bekannte ips-Server benötigen, sollte die einfachste Lösung die statische clientseitige Routing-Option sein.

In meinem Fall habe ich meinen gewünschten Zielserver (192.168.1.100) zu meiner Routing-Tabelle auf meinem Linux-Client hinzugefügt über:

route add 192.168.1.100 dev tun0

Entfernen Sie anschließend diese statische Route mit dem Befehl route delete.


13
2018-02-28 13:00



Dies ist eine perfekte Lösung und ein perfektes Timing! :) - Yuval A
Schnell und einfach. Vielen Dank. - Petr Přikryl
Wie lange dauert das? Bis Sie die Verbindung trennen? Bis zum Neustart? - carbocation
Auf meinem Linux-System (xfce mit ubuntu / mint) sind die Einstellungen nach einem VPN-Verbindungsabbau "verloren" und ja, auch nach einem Neustart. Sie können überprüfen, ob die Einstellung mit dem route-Befehl aktiv ist (es wird einen Eintrag geben, bei dem ip und das tun0-Gerät normalerweise unten stehen) - Aydin K.
Die OSX-Version der Route nimmt die Schnittstelle anders, also statt dev tun0 du brauchst -interface tun0 - Sirens


Das ist das Schlimmste. für mich geschah es die ganze zeit von Hotelzimmern, bevor es vpn Admins erkannte, dass sie mehr obskure IP-Bereiche verwenden sollten. 10.0.0.0/24 und 10.1.1.1/24 sind die schlimmsten. Wenn du es helfen kannst, dann höre niemals ein solches drahtloses Netzwerk.

Also ist die Antwort "reparieren" Sie den WAP, um ein anderes internes Netzwerk zu verwenden (zB 10.255.255.0/24) und geben Sie dann eine Differenz (dh ip in einem Bereich, der zurück zu corp vpn routen kann), oder wenn Sie keine haben / kann nicht Admin auf wap, gehen Sie einfach zu Starbucks. oder 20 Minuten Wardriving :)

Wenn dies nur in einer Laborumgebung ist, verwenden Sie einfach andere Bereiche.


5
2017-10-26 23:48



Dang wirklich? Es gibt keine bessere Option? - John Russell
Nicht, dass ich weiß .... das war schon immer ein Problem ... sieht aus wie jemand meine Antwort abgelehnt hat, aber nicht wirklich eine Lösung vorgeschlagen .... ha töte den Boten! - nandoP


Ich bin auf einem Mac mit El Capitan. Während die obigen Vorschläge für mich nicht funktionierten, führten sie mich zu einer funktionierenden Lösung:

  1. vor dem Starten von VPN, ausführen ifconfig
  2. starte das VPN, mach es ifconfig und notieren Sie, welches die neue Schnittstelle ist. In meinem Fall war es ppp0 mit einer IP-Adresse von 192.168.42.74

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

    sudo route add 192.168.1.79  192.168.42.74
    

Ich habe zuerst mit einem getestet ping und dann habe ich bewiesen, dass es funktionierte, indem ich auf den Git-Server zugreife.

Als ich es versuchte dev ppp0 für das Ende des Routenbefehls wie oben erwähnt, klagte es.


3
2018-06-21 00:51



Was ist 192.168.1.79 kommst du in diesem Austausch? - carbocation
Der Zielserver, mit dem Sie eine Verbindung herstellen. Dieser Server befindet sich im selben Netzwerk wie Ihr VPN, nicht Ihre lokale Verbindung. - Carlo del Mundo


Ich habe eine einfache Lösung, die ich in einem Co-Working-Space mit einem widersprüchlichen IP-Bereich (10.x) verwende

Ich habe mich mit meinem Handy mit dem Netzwerk verbunden, dann habe ich die Netzwerkverbindung via Bluetooth mit meinem Laptop geteilt. Ich kann jetzt das VPN für meinen entfernten Arbeitgeber verwenden.

Ich bin mir sicher, dass dies über USB genauso funktioniert, wenn Sie eine schnellere Verbindung benötigen.


1
2018-04-02 06:44



Hey, das ist eigentlich eine ziemlich clevere Lösung. - Nathan Osman


Wenn Sie nur ein oder zwei IP-Adressen eingeben müssen, fügen Sie route statement wie folgt in Ihre ovpn-Konfigurationsdatei ein:

Route 192.168.1.10 255.255.255.255

Route 192.168.1.11 255.255.255.255

Es wird eine Route nur für diese IPs hinzufügen, wenn Sie Ihren VPN verbinden und es entfernen, wenn der VPN es getrennt hat.

Arbeitete für mich sowieso unter Windows.


0
2018-05-23 16:10





Nur zur Erinnerung: Dieses ganze Problem ist auf die jahrelange IPv4-Adressknappheit und den extensiven Einsatz von. Zurückzuführen privater IP-Bereich hinter NAT um diesen Mangel zu umgehen!

Die ideale und endgültige Lösung für dieses Problem ist ziemlich einfach (obwohl es einige Zeit dauern kann und wird, bis es global eingeführt wird): IPv6...

In einer IPv6-Welt gibt es keinen öffentlichen IP-Mangel (und es wird auch kein Ereignis in ein paar Jahrzehnten geben). Es gibt also keinen Grund, keine öffentliche IP auf jedem Gerät in jedem Netzwerk zu haben. Und wenn Sie Netzwerkisolation benötigen, filtern Sie mit einer Firewall, aber ohne hässliches NAT ...


0
2017-09-04 20:42