Es ist möglich, dies mit NAT zu lösen. es ist einfach nicht sehr elegant.
Unter der Annahme, dass Sie dieses Problem nicht lösen können, indem Sie interne Netze verwenden, deren Netzwerknummern so ungewöhnlich sind, dass sie nie in Konflikt geraten, gilt das folgende Prinzip:
Da sowohl das lokale als auch das entfernte Subnetz identische Netzwerknummern haben, wird der Datenverkehr von Ihrem Client niemals erkennen, dass er das Tunnel-Gateway passieren muss, um sein Ziel zu erreichen. Und selbst wenn wir uns das vorstellen könnten, wäre die Situation für den Remote-Host dieselbe, da er eine Antwort senden wird.
Bleiben Sie also bei mir und tun Sie so, als ob es bis jetzt keine Nebenprobleme gibt, da ich schreibe, dass Sie für eine vollständige Konnektivität beide Enden innerhalb des Tunnels NAT benötigen würden, um die Hosts zu unterscheiden und das Routing zuzulassen.
Hier ein paar Netze basteln:
- Ihr Büronetzwerk verwendet 192.0.2.0/24
- Ihr Remote-Büro verwendet 192.0.2.0/24
- Das VPN-Gateway Ihres Büronetzwerks verbirgt 192.0.2.0/24 Hosts hinter der NATed-Netzwerknummer 198.51.100.0/24
- Das VPN-Gateway Ihres Remote-Office-Netzwerks verbirgt 192.0.2.0/24 Hosts hinter der NATed-Netzwerknummer 203.0.113.0/24
Innerhalb des VPN-Tunnels sind die Office-Hosts jetzt 198.51.100.x und die Remote-Office-Hosts 203.0.113.x. Nehmen wir weiterhin an, alle Hosts sind 1: 1 im NAT ihrer jeweiligen VPN-Gateways zugeordnet. Ein Beispiel:
- Ihr Büronetzwerkhost 192.0.2.5/24 ist statisch als 198.51.100.5/24 im NAT des Office-VPN-Gateways zugeordnet
- Ihr Remote-Office-Netzwerkhost 192.0.2.5/24 ist im Remote-Office-VPN-Gateway NAT statisch als 203.0.113.5/24 zugeordnet
Wenn der Host 192.0.2.5/24 im Remote-Büro eine Verbindung zum Host mit derselben IP im Office-Netzwerk herstellen möchte, muss er die Adresse 198.51.100.5/24 als Ziel verwenden. Folgendes passiert:
- In der Remote-Niederlassung ist Host 198.51.100.5 ein Remote-Ziel, das über das VPN erreicht und dort weitergeleitet wird.
- In der Remote-Niederlassung wird Host 192.0.2.5 als 203.0.113.5 maskiert, wenn das Paket die NAT-Funktion besteht.
- Im Büro wird Host 198.51.100.5 in 192.0.2.5 übersetzt, wenn das Paket die NAT-Funktion durchläuft.
- Im Büro wird der Rückverkehr zum Host 203.0.113.5 in umgekehrter Richtung durchgeführt.
Während es also eine Lösung gibt, gibt es eine Reihe von Problemen, die angegangen werden müssen, damit dies in der Praxis funktioniert:
- Die maskierte IP-Adresse muss für die Remoteverbindung verwendet werden. DNS wird komplex. Dies liegt daran, dass Endpunkte eine eindeutige IP-Adresse haben müssen, wie vom verbindenden Host aus gesehen.
- Eine NAT-Funktion muss beidseitig im Rahmen 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, muss nur das empfangende Ende alle beteiligten Hosts statisch zuordnen. Der Client kann davonkommen, dynamisch NAT-fähig zu sein, wenn dies gewünscht wird.
- Wenn der Datenverkehr bidirektional ist, müssen auf beiden Seiten alle beteiligten Hosts statisch zugeordnet werden.
- Die Internetverbindung darf unabhängig von Split- oder Non-Split-VPN nicht beeinträchtigt werden.
- Wenn Sie nicht 1-zu-1 abbilden können, wird es chaotisch. 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, ist sorgfältiges Design erforderlich. Wenn Ihr Remote-Büro wirklich aus Straßenkämpfern besteht, fügen Sie eine Reihe von Problemen hinzu:
- Sie wissen nie im Voraus, wann sie auf überlappende Netz-IDs stoßen.
- Das NAT des Remote-Office-Gateways muss auf den Laptops implementiert werden.
- Das Office-Gateway benötigt zwei VPNs, ein NAT-freies und ein NAT-fähiges, um beide Szenarien abzudecken. Andernfalls würde es nicht funktionieren , wenn jemand eines der Subnetze auswählt, die Sie für die NAT-Methode ausgewählt haben .
Abhängig von Ihrem VPN-Client können Sie abhängig von der Netzwerkadresse des lokalen Segments möglicherweise automatisch das eine oder das andere VPN auswählen.
Beachten Sie, dass jede Erwähnung von NAT in diesem Zusammenhang eine NAT-Funktion bedeutet, die sozusagen in der Tunnelperspektive stattfindet. Die statische NAT-Zuordnung muss prozessbedingt erfolgen, bevor das Paket in den Tunnel "eintritt", dh bevor es in das Transportpaket eingekapselt wird, das es über das Internet zum anderen VPN-Gateway bringen soll.
Dies bedeutet, dass man die öffentlichen IP-Adressen der VPN-Gateways (und die in der Praxis auch NAT-Adressen sein können, aber dann ganz außerhalb der Perspektive des Transports zum Remote-Standort über VPN) nicht mit den eindeutigen privaten Adressen verwechseln darf, die als Maskeraden verwendet werden für die doppelten privaten Adressen. Wenn sich diese Abstraktion nur schwer vorstellen lässt, wird hier veranschaulicht, wie NAT zu diesem Zweck physisch vom VPN-Gateway getrennt sein kann:
Verwenden von NAT in überlappenden Netzwerken .
Das gleiche Bild auf eine logische Trennung innerhalb eines Computers zu komprimieren, auf dem sowohl die NAT- als auch die VPN-Gateway-Funktionalität ausgeführt werden kann, führt dasselbe Beispiel lediglich einen Schritt weiter, wobei jedoch die Fähigkeiten der jeweiligen Software stärker betont werden. Es wäre eine Herausforderung, es zusammen mit OpenVPN und iptables zu hacken und die Lösung hier zu veröffentlichen.
Softwaremäßig ist es sicherlich möglich:
PIX / ASA 7.x und höher: LAN-zu-LAN-IPsec-VPN mit überlappenden Netzwerken Konfigurationsbeispiel
und:
Konfiguration eines IPSec-Tunnels zwischen Routern mit doppelten LAN-Subnetzen
Die tatsächliche Implementierung hängt daher nicht zuletzt von vielen Faktoren, den beteiligten Betriebssystemen, der zugehörigen Software und deren Möglichkeiten ab. Aber es ist durchaus machbar. Sie müssten ein bisschen nachdenken und experimentieren.
Ich habe das von Cisco gelernt, wie die Links zeigen.