Dasselbe Subnetz an beiden Enden: das entfernte LAN auf einen freien Bereich abbilden

Zuhause und Büro laufen beide auf 192.168.1.0/24, also hat eine Anfrage an 192.168.1.1 zwei mögliche Antworten, und der Client wählt eine, ohne zu fragen. Ein funktionierendes Büronetz umzunummerieren ist selten beliebt, und die Routeradressen sind oft in Drucker, Kameras und Dokumentation eingebrannt. Eine clientseitige Adressabbildung kann das entfernte Netz stattdessen unter einem freien Bereich darstellen, und der Hostteil kann gleich bleiben, sodass 192.168.1.20 als 10.203.41.20 erscheint. Der Haken ist, dass nur einige Clients sie umsetzen und sie für den Rückweg nichts tut.

Zwei Sichten auf denselben Host

Die Abbildung behält den Hostteil und ändert nur den Netzwerkteil. Dieselbe Maschine antwortet dann unter zwei Adressen, je nachdem, wo man steht. Beide Spalten vor der Konfiguration aufzuschreiben verhindert späteres Fehlinterpretieren von Protokollen und Firewall-Regeln.

Lokale Geräte zu Hause behalten ihre eigenen 192.168.1.x-Adressen, und das ist der Sinn der Übung. Der Drucker im Nebenraum bleibt erreichbar, während das Büro unter einem Bereich erscheint, der nicht kollidiert.

Die Argumentreihenfolge ist der ganze Trick

Die Option nimmt eine Richtung, ein Netz samt Maske und einen Alias: Das erste Netz ist das, was der Client sieht, der Alias ist das, was der Server sieht. Für Ressourcen hinter dem entfernten Gateway ist die Richtung die Zielform. Die beiden Netze zu vertauschen, weil das letzte Argument Alias heißt, ist der Fehler, der einen Tunnel erzeugt, der sich verbindet und nichts abbildet.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

Die Route schickt die Pakete des Clients für den neuen Bereich in den Tunnel; die Übersetzung schreibt das Ziel auf dem Weg um. Eine Antwort von 192.168.1.20 wird zurück auf 10.203.41.20 geschrieben, damit der Socket auf dem Client konsistent bleibt. Ein einzelner Host funktioniert genauso mit einer Maske voller Länge, solange Route und Abbildung dieselbe Adresse beschreiben.

Das ist eine Adressabbildung, keine Portweiterleitung. Zwei Dienste auf einem Host lassen sich damit nicht trennen, und ein Protokoll, das IP-Adressen in seine Nutzlast einbettet, sieht weiterhin die echten.

Die Abbildung erzeugt keinen Rückweg

Die Übersetzung geschieht beim Client, also muss der Server Antworten weiterhin in den Tunnel routen, und seine Firewall muss sie weiterhin erlauben. Wenn das entfernte Gateway nicht weiß, wie es das Tunnel-Subnetz erreicht, kommt die Anfrage an und die Antwort geht durch die falsche Tür hinaus; die Abbildung lässt den Fehler nur wie ein Clientproblem aussehen.

Regeln auf der Serverseite sollten die Adressen beschreiben, die nach der Übersetzung auf dem Server existieren, nicht den clientseitig sichtbaren Bereich. Den Alias in eine Allow-Regel zu kopieren kostet einen Nachmittag, weil kein Paket auf jener Seite ihn trägt.

Wählen Sie einen Alias-Bereich, der mit nichts anderem kollidiert, was der Client routet: ein anderes VPN, ein Containernetz, ein zweites Büro. Eine Kollision hier führt die ursprüngliche Mehrdeutigkeit unter einer anderen Nummer wieder ein und ist schwerer zu sehen, weil die Adressen unbekannt wirken.

Namen und Nutzlasten überleben die Übersetzung

Ein Hostname, der sich in die echte 192.168.1.20 auflöst, schickt den Browser auf das lokale Gerät statt auf das entfernte, egal was die Routing-Tabelle sagt. Die private DNS-Antwort muss auf den clientseitig sichtbaren Bereich zeigen, während das TLS-Zertifikat weiterhin den Namen trägt, den die Anwendung erwartet. Testen Sie mit dem Namen statt mit der Adresse, denn die Adresse kann funktionieren, während der Name still in die falsche Richtung auflöst. Wenn das entfernte Gateway diese Zone ebenfalls bedient, brauchen auch seine eigenen Einträge den clientseitig sichtbaren Bereich.

Weiterleitungen, eingebettete URLs und Anwendungen, die ihre eigene Adresse in einer Nutzlast ausgeben, können auf Arten brechen, die keine Paketabbildung reparieren kann. Behandeln Sie das als Anwendungsproblem und bemessen Sie den Aufwand entsprechend, bevor Sie versprechen, dass Umnummerieren unnötig ist.

Drei Prüfungen vor der Zusage

Erstens, bestätigen Sie die Client-Implementierung. Community OpenVPN unterstützt diese Option; die OpenVPN 3-Codebasis führt sie unter den nicht unterstützten Funktionen, sodass ein Profil, das an einen Client im Connect-Stil geschoben wird, sie einfach ignorieren kann. Eine Direktive, die akzeptiert und nie angewandt wird, ist schlimmer als ein Fehler, weil der Tunnel gesund aussieht.

Zweitens, prüfen Sie Route und Übersetzung getrennt mit einem kurzen Diagnosefenster bei hoher Ausführlichkeit und testen Sie dann den tatsächlichen Dienst statt eines Ping. Drittens, bestätigen Sie, dass der lokale Router und die entfernte Ressource vom Client unterscheidbar bleiben, denn das war das ursprüngliche Ziel.

Wenn der Client die Übersetzung nicht leisten kann, fragen Sie die Gateway-Seite um Hilfe oder akzeptieren Sie eine Umnummerierung. Mehr Routen für dieselbe Adresse hinzuzufügen ist kein Entwurf.