Windows NAT-T-registerverdi: kontroller topologien først

En Windows VPN-tilkobling feiler, et søk returnerer en registerverdi, og verdien legges inn sammen med en omstart. Den sekvensen virker noen ganger og forklarer aldri noe. Innstillingen det gjelder, besvarer ett spørsmål om hvor serveren står i forhold til en NAT-enhet, og den er meningsløs til du vet hvilken protokoll som feilet og i hvilken fase.

Hva verdien egentlig velger

AssumeUDPEncapsulationContextOnSendRule avgjør om en Windows-IPsec-implementasjon vil forsøke å opprette assosiasjoner med en peer bak en NAT-enhet. Standardverdien 0 tillater ikke det tilfellet, 1 tillater det når serveren er siden bak NAT, og 2 dekker at begge ender oversettes. Dette er topologiutsagn om hvem som er hvor.

Lest som en sekvens beskriver tallene stadig mer oversettelse, ikke stadig større pålitelighet. Å sette 2 på et nettverk der ingenting oversettes gjør ikke tilkoblingen raskere eller mer stabil, og det reparerer ikke en autentiseringsfeil. Microsofts veiledning om NAT for L2TP/IPsec dokumenterer policyen og dens historiske plattformkontekst. Hold den konteksten opp mot Windows-versjonen og -rollen du faktisk kjører, for et dokument som har overlevd flere utgivelser er ikke et utsagn om hver nåværende build.

Tilpass topologien før tallet

Tegn banen og merk oversettelsespunktene: sitter klienten bak en hjemmeruter, sitter serveren bak en lastbalanserer eller en brannmur som skriver om adresser, og ligger en av endene bak en operatørbasert oversettelse du ikke kontrollerer. Først etter den tegningen kan du avgjøre om verdien gjelder, og for hvilken ende.

Påstanden om at nåværende Windows Server-versjoner bare leveres med NAT-traversering deaktivert er for bred å handle på. Det som betyr noe, er policyen på systemet ditt, topologien foran det og utvekslingen som feilet, i den rekkefølgen. Hvis begge ender har offentlige adresser, er innstillingen ikke ditt problem. Se i stedet på forslaget, sertifikatet eller kontoen, og la registeret være.

Kontroller feilfasen først

L2TP/IPsec gir minst tre ulike feil: peeren er ikke nåbar, IPsec-beskyttelse kan ikke etableres, og PPP-brukerautentisering avvises etter at tunnelen finnes. En avvist konto kan ikke repareres ved å endre NAT-policy, og et forslagsavvik kan ikke repareres ved å starte på nytt.

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 tidsavbrudd uten svar antyder nåbarhet eller filtrering snarere enn policy. En rask avvisning med en forslagsmelding peker på algoritmer. En feil etter at tunnelen er oppe, hører til autentiseringsfasen, som er en annen eier og en annen løsning.

SSTP over HTTPS og innebygd IKEv2 har egne logger og egne kontroller. Ingenting av det blir en NAT-traverseringssak bare fordi de også kjører på Windows.

Gjør endringen med en vei tilbake

Hvis den dokumenterte policyen og den observerte topologien begge krever det, noter den forrige verdien, bruk endringen via den administrerte konfigurasjonen i stedet for et skript per profil, og planlegg omstarten. På en server som støtter andre arbeidsbelastninger er dette ikke en uskyldig endring.

NAT-enheten må fortsatt bære den innkapslede transporten og returtrafikken. En registerverdi lager ingen videresendingsregel, justerer ingen forslag og validerer ingen identitet, så en tilkobling som begynner å virke etter endringen kan virke av en helt annen grunn. Test den opprinnelige protokollen med den opprinnelige topologien på nytt, og skriv deretter ned hvilken fase som feilet og hvorfor verdien var forventet å løse det. Den setningen er det som gjør et internettrykte til en konfigurasjon du kan forsvare.