Windows NAT-T-registerværdi: kontroller topologien først

En Windows-VPN-forbindelse fejler, en søgning returnerer en registerværdi, og værdien indsættes sammen med en genstart. Den sekvens virker nogle gange og forklarer aldrig noget. Den pågældende indstilling besvarer ét spørgsmål om, hvor serveren ligger i forhold til en NAT-enhed, og den er meningsløs, indtil du ved, hvilken protokol der fejlede, og i hvilken fase.

Hvad værdien egentlig vælger

AssumeUDPEncapsulationContextOnSendRule afgør, om en Windows-IPsec-implementering vil forsøge at oprette associationer til en peer bag en NAT-enhed. Standardværdien 0 tillader ikke det tilfælde, 1 tillader det, når serveren er den side, der ligger bag NAT, og 2 dækker, at begge ender oversættes. Det er topologiske udsagn om, hvem der er hvor.

Læst som en sekvens beskriver tallene stadig mere oversættelse, ikke stadig større pålidelighed. At sætte 2 på et netværk, hvor intet oversættes, gør ikke forbindelsen hurtigere eller mere stabil, og det reparerer ikke en godkendelsesfejl. Microsofts vejledning om NAT til L2TP/IPsec dokumenterer politikken og dens historiske platformskontekst. Hold den kontekst op mod den Windows-version og -rolle, du faktisk kører, for et dokument, der har overlevet flere udgivelser, er ikke et udsagn om enhver nuværende build.

Afstem topologien før tallet

Tegn stien og markér oversættelsespunkterne: sidder klienten bag en hjemmerouter, sidder serveren bag en load balancer eller en firewall, der omskriver adresser, og ligger en af enderne bag en carrier-oversættelse, du ikke kontrollerer. Først efter den tegning kan du afgøre, om værdien gælder, og for hvilken ende.

Påstanden om, at aktuelle Windows Server-versioner blot leveres med NAT traversal deaktiveret, er for bred at handle på. Det, der betyder noget, er politikken på dit system, topologien foran det og den udveksling, der fejlede, i den rækkefølge. Hvis begge ender har offentlige adresser, er indstillingen ikke dit problem. Se i stedet på forslaget, certifikatet eller kontoen, og lad registret være.

Kontroller fejlfasen først

L2TP/IPsec giver mindst tre forskellige fejl: peer'en kan ikke nås, IPsec-beskyttelse kan ikke etableres, og PPP-brugerens godkendelse afvises, efter at tunnelen findes. En afvist konto kan ikke repareres ved at ændre NAT-politik, og et forslagsmismatch kan ikke repareres ved at genstarte.

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 uden svar antyder tilgængelighed eller filtrering snarere end politik. En hurtig afvisning med en forslagsmeddelelse peger på algoritmer. En fejl, efter at tunnelen er oppe, hører til godkendelsesfasen, som er en anden ejer og en anden løsning.

SSTP over HTTPS og indbygget IKEv2 har deres egne logfiler og deres egne kontroller. Intet af det bliver en NAT-traversal-sag, blot fordi de også kører på Windows.

Udfør ændringen med en vej tilbage

Hvis den dokumenterede politik og den observerede topologi begge kræver det, skal du notere den tidligere værdi, anvende ændringen via den administrerede konfiguration i stedet for et script pr. profil og planlægge genstarten. På en server, der understøtter andre arbejdsbelastninger, er det ikke en uskyldig ændring.

NAT-enheden skal stadig transportere den indkapslede trafik og returtrafikken. En registerværdi opretter ingen videresendelsesregel, afstemmer ingen forslag og validerer ingen identitet, så en forbindelse, der begynder at virke efter ændringen, kan virke af en helt anden grund. Test den oprindelige protokol med den oprindelige topologi igen, og skriv derefter ned, hvilken fase der fejlede, og hvorfor værdien skulle løse det. Den sætning er det, der gør et internetrygte til en konfiguration, du kan forsvare.