NAT sollte sich für jede Applikation, die damit arbeitet, transparent verhalten. Viele NAT- und VPN-Dilemmas basieren auf der Annahme, dass dies tatsächlich der Fall ist. NAT kann einen VPN-Tunnel unterbrechen, da NAT die Layer 3-Netzwerkadresse eines Pakets (und die Prüfsumme) ändert, wogegen das Tunneling im Rahmen eines IPSec oder L2TP VPN-Gateways die Layer 3-Netzwerkadresse eines Pakets mit einer anderen Layer 3-Netzwerkadresse umschließt/verschlüsselt, die am anderen Ende wieder entfernt wird.
Mit anderen Worten: Nachdem ein Paket den NAT-Prozess durchlaufen hat, hat es eine andere Netzwerkadresse. Ein Paket aber, dass den IPSec oder L2TP VPN-Tunneling-Prozess durchlaufen hat, trägt noch dieselbe Netzwerkadresse. Dieses Konzept ist bei der Problemsuche und Einrichtung von NAT und VPN unschätzbar.
Wie gesagt, mit PPTP können Probleme mit NAT-VPN aufgrund von IPSec und/oder L2TP häufig umgangen werden. Wenn Sie allerdings einen Tunnel durchs Internet mit zwei Cisco-Routern (oder anderen Geräten oder Betriebssystemen, die nicht von Microsoft sind) erstellen möchten, verwenden Sie wahrscheinlich IPSec. Wenn Sie IPSec mit NAT auf einem Cisco-Router einsetzen, können Sie das VPN-NAT-Problem lösen, indem Sie den eigentlich zu NATenden Verkehr wählen und sicherstellen, dass dieser Verkehr eben nicht geNATet wird, sondern im IPSec-Header eingeschlossen und verschlüsselt wird.
Mit anderen Worten: Sorgen Sie dafür, dass Daten, deren Ziel wirklich das Internet ist, geNATet werden, während Daten, die den IPSec-Tunnel durchwandern nur getunnelt werden und nicht geNATet. Bei Cisco können Sie dies durch eine Zugriffskontrollliste steuern.
Zurück zu unserem Szenario mit dem gebeutelten Netzwerk-Administrator, der eine Workstation mit privater IP-Adresse konfiguriert und sich bemüht, einen VPN-Client über einen Router mit NAT zu verwenden. In unserem Beispiel verwendet der Administrator einen VPN-Client auf IPSec-Basis (nicht PPTP). Da es sich um eine Client-Server-Beziehung handelt, verwendet der Admin IPSec im Transport-Modus.
Im Transport-Modus wird der IP-Header nicht verschlüsselt, sondern ist offen. Allerdings werden die Authentisierungsdaten auf Basis der Werte im IP-Header (und einigen anderen Sachen) berechnet. Wenn die Pakete am NAT-Router eintreffen, werden die IP-Header geändert (NATet). Bei Ankunft am VPN-Server sind die Authentisierungsdaten ungültig, da die IP-Headerdaten von NAT geändert wurden. Daher übergeht der VPN-Server das Paket, so dass der VPN-Client nie eine Verbindung erhält.
Zur Lösung dieses Problems integrieren VPN-Lieferanten IPSec-NAT-Umsetzungsfähigkeiten. Zu diesem Zweck werden verschiedene Standards und Implementationen eingesetzt. Die meisten verwenden eine Art IPSec-Encapsulation in UDP-Pakete. Da das IPSec-Paket nun eingeschlossen ist, ändern NAT-Geräte die IP-Headerdaten nicht, und die IPSec-Authentisierung ist nach wie vor gültig. Damit ist eine Verbindung möglich.
Huawei stellt auf der Connect Europe 2024 in Paris mit Xinghe Intelligent Network eine erweiterte…
Höchste Zeit für eine schnelle Kupfer-Glas-Migration. Bis 2030 soll in Deutschland Glasfaser flächendeckend ausgerollt sein.
Schon im April 2025 soll Android 16 den Status Plattformstabilität erreichen. Entwicklern gibt Google danach…
Die Hintermänner setzen KI-Chatbot-Tools als Köder ein. Opfer fangen sich den Infostealer JarkaStealer ein.
Vernetzte Produkte müssen laut Cyber Resilience Act über Möglichkeiten zur Datenverschlüsselung und Zugangsverwaltung verfügen.
Das jüngste Update für Windows, macOS und Linux stopft drei Löcher. Eine Anfälligkeit setzt Nutzer…