Windows NAT-T-registervärde: kontrollera topologin först

En Windows VPN-anslutning misslyckas, en sökning returnerar ett registervärde och värdet förs in tillsammans med en omstart. Den sekvensen fungerar ibland och förklarar aldrig något. Inställningen det gäller besvarar en fråga om var servern står i förhållande till en NAT-enhet, och den är meningslös tills du vet vilket protokoll som misslyckades och i vilken fas.

Vad värdet egentligen väljer

AssumeUDPEncapsulationContextOnSendRule avgör om en Windows-IPsec-implementering kommer att försöka skapa associationer med en peer bakom en NAT-enhet. Standardvärdet 0 tillåter inte det fallet, 1 tillåter det när servern är sidan bakom NAT, och 2 täcker att båda ändarna översätts. Det är topologipåståenden om vem som är var.

Läst som en sekvens beskriver siffrorna allt mer översättning, inte allt högre tillförlitlighet. Att sätta 2 i ett nät där ingenting översätts gör inte anslutningen snabbare eller stabilare och reparerar inte ett autentiseringsfel. Microsofts vägledning om NAT för L2TP/IPsec dokumenterar policyn och dess historiska plattformskontext. Jämför den kontexten med den Windows-version och roll du faktiskt kör, för ett dokument som överlevt flera versioner är inget påstående om varje aktuell build.

Anpassa topologin före siffran

Rita vägen och markera översättningspunkterna: sitter klienten bakom en hemrouter, sitter servern bakom en lastbalanserare eller en brandvägg som skriver om adresser, och ligger någon av ändarna bakom en operatörsöversättning du inte kontrollerar. Först efter den ritningen kan du avgöra om värdet gäller, och för vilken ände.

Påståendet att nuvarande Windows Server-versioner bara levereras med NAT-traversering avstängd är för brett att agera på. Det som spelar roll är policyn på ditt system, topologin framför det och utbytet som misslyckades, i den ordningen. Om båda ändarna har offentliga adresser är inställningen inte ditt problem. Titta i stället på förslaget, certifikatet eller kontot och låt registret vara.

Kontrollera felets fas först

L2TP/IPsec ger minst tre olika fel: peeren går inte att nå, IPsec-skydd kan inte upprättas, och PPP-användarautentisering avvisas efter att tunneln finns. Ett avvisat konto kan inte repareras genom att ändra NAT-policy, och en förslagsavvikelse kan inte repareras genom omstart.

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

En timeout utan svarare tyder på nåbarhet eller filtrering snarare än policy. En snabb avvisning med ett förslagsmeddelande pekar på algoritmer. Ett fel efter att tunneln är uppe hör till autentiseringsfasen, vilket är en annan ägare och en annan lösning.

SSTP över HTTPS och inbyggd IKEv2 har egna loggar och egna kontroller. Inget av det blir ett NAT-traverseringsfall bara för att de också körs på Windows.

Gör ändringen med en väg tillbaka

Om den dokumenterade policyn och den observerade topologin båda kräver det, anteckna det tidigare värdet, tillämpa ändringen via den hanterade konfigurationen i stället för ett skript per profil, och planera omstarten. På en server som stöder andra arbetsbelastningar är detta ingen oskyldig ändring.

NAT-enheten måste fortfarande bära den inkapslade trafiken och returtrafiken. Ett registervärde skapar ingen vidarebefordringsregel, justerar inga förslag och validerar ingen identitet, så en anslutning som börjar fungera efter ändringen kan fungera av en helt annan anledning. Testa det ursprungliga protokollet med den ursprungliga topologin igen och skriv sedan ned vilken fas som misslyckades och varför värdet förväntades lösa det. Den meningen är det som gör ett internetrykte till en konfiguration du kan försvara.