Windows-NAT-T-Registrierungswert: zuerst die Topologie prüfen

Eine Windows-VPN-Verbindung scheitert, eine Suche liefert einen Registrierungswert, und der Wert wird zusammen mit einem Neustart eingetragen. Diese Abfolge funktioniert manchmal und erklärt nie etwas. Die fragliche Einstellung beantwortet eine Frage dazu, wo der Server relativ zu einem NAT-Gerät steht, und sie ist bedeutungslos, bis man weiß, welches Protokoll in welcher Phase gescheitert ist.

Was der Wert tatsächlich auswählt

AssumeUDPEncapsulationContextOnSendRule bestimmt, ob eine Windows-IPsec-Implementierung Assoziationen mit einem Peer hinter einem NAT-Gerät aufbauen wird. Der dokumentierte Standardwert 0 erlaubt diesen Fall nicht, 1 erlaubt ihn, wenn der Server die Seite hinter NAT ist, und 2 deckt ab, dass beide Enden übersetzt werden. Das sind Topologieaussagen darüber, wer wo steht.

Als Sequenz gelesen beschreiben die Zahlen zunehmend mehr Übersetzung statt zunehmend mehr Zuverlässigkeit. Der Wert 2 in einem Netz, in dem nichts übersetzt wird, macht die Verbindung weder schneller noch stabiler und behebt keinen Authentifizierungsfehler. Microsofts Leitfaden zu NAT bei L2TP/IPsec dokumentiert die Richtlinie und ihren historischen Plattformkontext. Prüfen Sie diesen Kontext gegen die Windows-Version und -Rolle, die Sie tatsächlich betreiben, denn ein Dokument, das mehrere Releases überlebt hat, ist keine Aussage über jeden aktuellen Build.

Erst die Topologie abgleichen, dann die Zahl

Zeichnen Sie den Pfad und markieren Sie die Übersetzungspunkte: Steht der Client hinter einem Heimrouter, steht der Server hinter einem Load Balancer oder einer Firewall, die Adressen umschreibt, und liegt eines der Enden hinter einer Anbieter-Übersetzung, die Sie nicht kontrollieren. Erst nach dieser Zeichnung können Sie entscheiden, ob der Wert gilt und für welches Ende.

Die Behauptung, aktuelle Windows-Server-Versionen würden einfach mit deaktiviertem NAT-Traversal ausgeliefert, ist zu pauschal, um danach zu handeln. Entscheidend sind die Richtlinie auf Ihrem System, die Topologie davor und der fehlgeschlagene Austausch, in dieser Reihenfolge. Sind beide Enden öffentlich adressiert, ist die Einstellung nicht Ihr Problem. Sehen Sie stattdessen den Vorschlag, das Zertifikat oder das Konto an und lassen Sie die Registrierung in Ruhe.

Zuerst die Fehlerphase prüfen

L2TP/IPsec erzeugt mindestens drei verschiedene Fehler: Der Peer ist nicht erreichbar, IPsec-Schutz lässt sich nicht aufbauen, und die PPP-Benutzerauthentifizierung wird nach Bestehen des Tunnels abgelehnt. Ein abgelehntes Konto lässt sich nicht durch eine Änderung der NAT-Richtlinie reparieren, und eine Vorschlagsabweichung lässt sich nicht durch einen Neustart reparieren.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

Ein Timeout ohne Antwort spricht eher für Erreichbarkeit oder Filterung als für die Richtlinie. Eine schnelle Ablehnung mit einer Vorschlagsmeldung deutet auf Algorithmen. Ein Fehler nach dem Aufbau des Tunnels gehört zur Authentifizierungsphase, die einen anderen Verantwortlichen und eine andere Lösung hat.

SSTP über HTTPS und natives IKEv2 haben ihre eigenen Protokolle und ihre eigenen Kontrollen. Nichts davon wird zum NAT-Traversal-Fall, nur weil es auch unter Windows läuft.

Die Änderung mit einem Rückweg vornehmen

Wenn die dokumentierte Richtlinie und die beobachtete Topologie beide dafür sprechen, notieren Sie den vorherigen Wert, wenden Sie die Änderung über die verwaltete Konfiguration statt über ein Skript pro Profil an und planen Sie den Neustart. Auf einem Server, der andere Arbeitslasten trägt, ist das keine harmlose Bearbeitung.

Das NAT-Gerät muss den gekapselten Transport und den Rückverkehr weiterhin tragen. Ein Registrierungswert erzeugt keine Weiterleitungsregel, gleicht keine Vorschläge ab und validiert keine Identität, sodass eine Verbindung, die nach der Änderung zu funktionieren beginnt, aus einem ganz anderen Grund funktionieren kann. Testen Sie das ursprüngliche Protokoll mit der ursprünglichen Topologie erneut und schreiben Sie dann auf, welche Phase gescheitert ist und warum der Wert sie beheben sollte. Dieser Satz macht aus einem Internetgerücht eine Konfiguration, die Sie verteidigen können.