RRAS-VPN-Clients brauchen einen eigenen IPv4-Pool und einen Rückweg

Der VPN-Client verbindet sich und erhält eine Adresse, doch der LAN-Host, den er braucht, kann ihm weiterhin nicht antworten. In Windows Routing and Remote Access stammt die innere Adresse für VPN-Clients aus einem Pool, der getrennt vom LAN-Adapter des Servers konfiguriert wird, und die LAN-Seite braucht eine Route zurück zu diesem Pool. Zwei Änderungen, nicht eine, und sie scheitern auf unterschiedliche Weise. Arbeiten Sie sie der Reihe nach ab, damit Adressplan und Rückweg belegt sind, bevor alte Bereiche außer Betrieb gehen.

Reservieren Sie den Bereich, bevor Sie die Konsole öffnen

Wählen Sie ein Präfix, das sich nicht mit dem LAN, anderen VPN-Bereichen oder irgendetwas, das in den Standort geroutet wird, überschneidet. Ein /24 ist eine praktische Größe für einen Test, und der erste nutzbare Teil kann an Clients gehen, während der Rest für Wachstum frei bleibt. Schreiben Sie ihn mit Zweck und Verantwortlichem auf, bevor Sie ihn in eine Konsole tippen. Lassen Sie an beiden Enden des Blocks Platz, damit eine spätere Teilung keine Umnummerierung erzwingt.

Ein Adressplan, der nur in einer Konsole lebt, ist einen Neuaufbau von einer Kollision entfernt. Er neigt auch zum Wachsen: Jemand fügt später einen zweiten Bereich hinzu, und niemand prüft den ersten. Bewahren Sie den Plan neben der Serverdokumentation auf, nicht in einem Chat-Thread.

Der LAN-Adapter des Servers definiert diesen Pool nicht. Den öffentlichen Listener zu ändern oder einen Adapter zum LAN hinzuzufügen, bewirkt etwas völlig anderes. Deshalb können sich Clients verbinden und trotzdem eine Adresse vom falschen Ort erhalten. Der Pool lebt in den IPv4-Eigenschaften des Servers, nicht in der Adapterliste.

Die Methode zu wechseln heißt nicht, einen Bereich hinzuzufügen

RRAS hat eine Zuweisungsmethode und eine Reihe von Bereichen. Der Wechsel von DHCP zu einem statischen Pool ist eine Methodenänderung. Einen weiteren Block hinzuzufügen, während der statische Pool bereits aktiv ist, ist eine Bereichsänderung.

Sehen Sie sich beide Vorgänge an, bevor Sie einen davon ausführen, und lesen Sie, welcher zum aktuellen Zustand des Servers passt:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

Das zweite Cmdlet schlägt fehl oder erzeugt einen unbrauchbaren Pool, wenn der Server noch auf DHCP-Zuweisung steht. Das erste ersetzt die Methode, statt einen vorhandenen Pool zu erweitern. Keine der Vorschauen wendet etwas an, führen Sie also die passende aus und bestätigen Sie danach den resultierenden Pool in der Konsole. Wenn Sie unsicher sind, in welchem Zustand der Server ist, lesen Sie die Zuweisungsmethode auf der Seite mit den IPv4-Eigenschaften und listen Sie die konfigurierten Bereiche auf:

Get-VpnIPAddressRange

Die Methode DHCP mit einer leeren Bereichsliste bedeutet, dass die erste Vorschau gilt. Ein statischer Adresspool mit einem vorhandenen Bereich bedeutet, dass die zweite gilt.

Rechnen Sie mit dem Dienstneustart, den die Einstellung erfordern kann, und gehen Sie nicht davon aus, dass verbundene Clients sofort umnummeriert werden. Ein Client, der seine alte Adresse behält, bis er sich erneut verbindet, verhält sich normal. Planen Sie die Änderung für ein Fenster, in dem eine erneute Verbindung akzeptabel ist.

Das LAN braucht eine Rückroute

Angenommen, das LAN ist 10.60.0.0/24 und der RRAS-Server ist 10.60.0.10 darin. Ein Host in diesem LAN, der einem Client in 10.250.50.0/24 antwortet, braucht einen Weg zum Pool über den RRAS-Server. Ohne diesen Weg kommt die Anfrage an, und die Antwort stirbt.

Ist das Standard-Gateway des Hosts ein anderer Router, braucht dieser Router die Rückroute für das VPN-Präfix. Eine statische Route auf dem RRAS-Server hilft hier nicht; der Rückweg muss auf dem Gerät existieren, dem das LAN-Gateway gehört, fügen Sie ihn also der Routing-Tabelle oder dem dynamischen Routingprozess hinzu, je nachdem, was der Standort verwendet.

Prüfen Sie auch die Firewall des Hosts und alle Netzwerkzugriffsregeln gegen den neuen Quellbereich. Regeln, die für den alten Client-Bereich geschrieben wurden, weisen den neuen ab, selbst wenn die Zuweisung erfolgreich war. Client-Routen zum LAN und die DNS-Auflösung sind getrennte Anforderungen, und beide können fehlschlagen, während der Tunnel gesund aussieht. Testen Sie jede für sich.

Belegen Sie den neuen Pool an einem Gerät, bevor Sie den alten außer Betrieb nehmen

Nehmen Sie eine Autorisierung, die Sie kontrollieren, verbinden Sie sich erneut und lesen Sie die Pool-Adresse, die der Client erhalten hat. Diese eine Zahl trennt Zuweisung von Routing. Üben Sie dann eine benannte Anwendung aus, beobachten Sie den Rückverkehr und probieren Sie ein Ziel, das verweigert bleiben soll. Drei Beobachtungen, drei verschiedene Fehlerarten.

Die Namensauflösung verdient einen eigenen Test: Zugriff über IP kann funktionieren, während das DNS des Clients noch auf einen Resolver zeigt, den er nicht erreichen kann. Ein DNS-Server im LAN ist nur erreichbar, wenn der Client eine Route dorthin hat und der Server Abfragen aus dem neuen Bereich annimmt. Beides sind häufige Lücken, wenn der Pool umzieht.

Nehmen Sie alte Bereiche und ihre Ausnahmen erst außer Betrieb, nachdem Sie aktive Sitzungen und den Wartungsprozess berücksichtigt haben. Ein verbundener Client mit einer neuen Adresse belegt die Zuweisung, nicht die Zugriffsrichtlinie. Halten Sie den alten Bereich dokumentiert, bis die letzte Sitzung, die ihn genutzt hat, abgelaufen ist.

Prüfen Sie das Ergebnis mit drei Beobachtungen

Abnahme braucht drei Fakten: Der Client hat eine Adresse aus dem neuen Pool, ein LAN-Host kann ihn erreichen und eine Antwort erhalten, und ein verweigertes Ziel bleibt verweigert. Jedes hat seine eigene Prüfung, ein Fehler zeigt also auf Zuweisung, Routing oder Richtlinie. Führen Sie sie in dieser Reihenfolge aus.

Bestätigen Sie vom Client aus die Adresse und die Route zu einem LAN-Host:

ipconfig | findstr /i "IPv4"
route print -4

Bestätigen Sie vom LAN-Host aus den Rückweg und die Richtlinie in einem Durchgang. Wenn Ping fehlschlägt, die Anwendung aber funktioniert, ist das fehlende Teil wahrscheinlich eine ICMP-Regel und nicht die Route. Wenn beides fehlschlägt, lesen Sie die Route auf dem Host, bevor Sie das VPN bearbeiten. Notieren Sie die drei Ergebnisse im Änderungsticket, damit die nächste Person mit Belegen beginnt.