Eine Verbindung als Standardroute auf einem Laptop zu markieren, ist der Schritt, den alle im Gedächtnis behalten, und genau der ändert am Gateway nichts. Der Client schickt die Internetanfragen jetzt in den Tunnel; ob sie das Gebäude verlassen, hängt von Weiterleitung, einem Übersetzungspunkt und einem Rückweg ab, der die private Adresse des Clients erreicht. Zwei Anordnungen können alle drei liefern, sie legen die Arbeit an verschiedene Stellen, und beide scheitern auf dieselbe stille Weise, wenn niemand die Antwortrichtung verantwortet. Die Wahl zwischen ihnen ist die Frage, wer den Client-Pool sehen soll.

Der Mythos: Eine Client-Route baut den Ausgang

Erzwungenes Tunneling ist eine Richtlinie auf der Clientseite: Sie entscheidet, dass der Verkehr an den VPN-Adapter statt an den physischen geht. Microsofts Dokumentation zum VPN-Routing beschreibt dieses Aufteilungs- und Erzwingungsverhalten, und das ist eine Aussage über die Routentabelle des Clients, nicht über die Weiterleitungsregeln des Servers. Aus Sicht des Clients ist der Tunnel der Ort, an dem das Internet lebt; aus Sicht des Gateways kam ein Paket von einer Adresse, von der weiter oben niemand je gehört hat. Keine Seite ist für sich falsch konfiguriert, und deshalb wirkt der Fehler für die Person am Laptop wie ein kaputter Server.

Diese Diskrepanz ist das ganze Problem, das der Rest dieses Artikels löst. Etwas muss die private Adresse des Clients rückführbar machen, und die Wahl ist, wo.

Zeichnen Sie zuerst den Antwortweg

Schreiben Sie den Weg mit echten Adressen auf, bevor Sie eine Einstellung anfassen, und markieren Sie die beiden möglichen Übersetzungspunkte darauf. Dieses Labor verwendet einen VPN-Pool von 10.70.0.0/24 mit einem Client unter 10.70.0.37, eine Server-LAN-Adresse von 172.16.40.10, einen Router unter 172.16.40.1 und einen öffentlichen Ausgang von 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Der Server, der bereits im Internet surft, beweist nur seinen eigenen Weg. Ein im Namen eines Clients weitergeleitetes Paket ist eine andere Entscheidung, getroffen von der Weiterleitungsrichtlinie auf derselben Maschine, und genau die fehlt meist. Die drei Entscheidungspunkte im Diagramm zu markieren, hält das Gespräch jeweils bei einem von ihnen.

Option A: Übersetzen auf dem VPN-Server

Hier übersetzt der Server die Quelle des Clients in seine eigene LAN-Adresse, bevor er das Paket an den Router übergibt, und der Router wendet auf dem Weg nach draußen seine übliche Übersetzung an. Auf dem Rückweg stellt die Zuordnung des Routers die Serveradresse wieder her, und die Zuordnung des Servers stellt die Clientadresse wieder her. Zwei zustandsbehaftete Übersetzungen hintereinander sind normal und machbar, sofern beide aufgezeichnet werden; der Router braucht nie eine Route zum Pool, und das ist der Reiz dieser Anordnung.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Nutzen Sie diese Ausgaben, um zu sehen, was der Server bereits hat, statt anzunehmen, dass ein NAT vorhanden ist. Eine aus einem Blog kopierte Linux-Masquerade-Regel ist keine Windows-Konfiguration, und eine Freigabe in der Host-Firewall für den VPN-Listener ist nicht dieselbe Richtlinie wie die Erlaubnis, die Anfrage eines Clients weiterzuleiten. Bestätigen Sie die Weiterleitungsrolle des Servers über dessen eigene Verwaltungsoberfläche, und sehen Sie sich die Übersetzung dann getrennt an, weil beide oft von verschiedenen Teilen einer Bereitstellung aktiviert werden.

Option B: Den Pool zum Router tragen

In der zweiten Anordnung leitet der Server die echte Quelladresse des Clients weiter, und der Router übersetzt sie. Das hält den Client-Pool am Rand sichtbar, was hilft, wenn der Router der Ort für Verkehrsrichtlinie, Protokollierung oder Inspektion ist. Es bedeutet auch, dass der Router eine Rückroute für 10.70.0.0/24 benötigt, die auf 172.16.40.10 zeigt, plus eine Internetrichtlinie, die dieses Präfix tatsächlich einschließt; eine für das LAN-Subnetz geschriebene Regel erstreckt sich nicht stillschweigend auf den Pool.

Wählen Sie dies, wenn das Randgerät der vorgesehene Richtlinieneigentümer ist und ein weiteres Präfix in seinen Routing- und Übersetzungstabellen akzeptieren kann. Wählen Sie die serverseitige Übersetzung, wenn der Pool weiter oben unsichtbar bleiben soll und der Router nicht vom selben Team administriert wird. Keine der Optionen wird durch ein Kontrollkästchen auf dem Client impliziert, und keine ist generell sicherer; sie platzieren Sichtbarkeit und Wartung an verschiedene Stellen.

DNS, IPv6 und Abnahme ausdrücklich machen

Adressübersetzung behebt die Namensauflösung nicht. Der Client kann einen Resolver verwenden, der mit dem VPN-Profil geliefert wird, einen privaten Resolver für bestimmte Namensräume oder einen genehmigten öffentlichen, und ein nicht erreichbarer Resolver unter dieser Richtlinie wird weiter scheitern, nachdem das Routing funktioniert. Testen Sie einen Namen und eine Adresse getrennt, damit die beiden Fehler nie in einem Bericht verschmelzen.

IPv6 braucht einen eigenen Absatz im Design. Eine funktionierende IPv4-Übersetzung sagt nichts darüber aus, ob IPv6-Clients eine Route, eine gültige öffentliche Quelle oder eine Richtlinie haben, die sie blockiert, wenn der Tunnel ausfällt. Das unausgesprochen zu lassen bedeutet, dass die Hälfte der Clients das Gateway still umgeht, während die andere Hälfte funktioniert.

Verfolgen Sie für die Abnahme eine erlaubte Clientanfrage und ihre Antwort über beide Grenzen und notieren Sie, welche Adresse jede Grenze in diesem Moment sehen sollte. Dieser Eintrag macht die nächste Pool-Änderung zu einer fünfminütigen Bearbeitung statt zu einer Diskussion darüber, wer die fehlende Rückroute besitzt. Bewahren Sie den Eintrag beim Clientprofil auf und nicht in einem Ticket, denn das Profil ist das, was der nächste Engineer zuerst findet.

Ähnliche Artikel