Windows NAT-T-registerwaarde: kyk eers na die topologie

’n Windows-VPN-verbinding misluk, ’n soektog lewer ’n registerwaarde op, en die waarde word saam met ’n herlaai ingesit. Daardie volgorde werk soms en verduidelik nooit iets nie. Die instelling ter sprake beantwoord een vraag oor waar die bediener ten opsigte van ’n NAT-toestel sit, en dit is betekenisloos totdat jy weet watter protokol misluk het en in watter stadium.

Wat die waarde werklik kies

AssumeUDPEncapsulationContextOnSendRule bepaal of ’n Windows-IPsec-implementering assosiasies met ’n eweknie agter ’n NAT-toestel sal probeer. Die gedokumenteerde verstek van 0 laat daardie geval nie toe nie; 1 laat dit toe wanneer die bediener die kant agter NAT is, en 2 dek albei kante wat vertaal word. Dit is topologieverklarings oor wie waar is.

As ’n reeks gelees, beskryf die getalle progressief meer vertaling eerder as progressief meer betroubaarheid. Om 2 te stel op ’n netwerk waar niks vertaal word nie, maak die verbinding nie vinniger of stabieler nie, en dit herstel nie ’n verifikasiefout nie. Microsoft se L2TP/IPsec-riglyne oor NAT dokumenteer die beleid en die historiese platformkonteks daarvan. Toets daardie konteks teen die Windows-weergawe en -rol wat jy werklik gebruik, want ’n dokument wat verskeie weergawes oorleef het, is nie ’n verklaring oor elke huidige bou nie.

Pas die topologie aan voordat jy die nommer kies

Teken die pad en merk die vertalingspunte: is die kliënt agter ’n tuisrouter, is die bediener agter ’n lasbalanseerder of ’n firewall wat adresse herskryf, en sit enige kant agter diensverskaffervertaling wat jy nie beheer nie. Eers ná daardie tekening kan jy besluit of die waarde van toepassing is, en op watter kant.

Die bewering dat huidige Windows Server-weergawes bloot met NAT-traversal gedeaktiveer gestuur word, is te breed om op te handel. Wat saak maak, is die beleid op jou stelsel, die topologie daarvoor en die uitruiling wat misluk het, in daardie volgorde. As albei kante publiek geadresseer is, is die instelling nie jou probleem nie. Kyk eerder na die voorstel, die sertifikaat of die rekening, en laat die register staan.

Kyk eers na die mislukkingsfase

L2TP/IPsec lewer minstens drie verskillende mislukkings: die eweknie is onbereikbaar, IPsec-beskerming kan nie tot stand gebring word nie, en die PPP-gebruikersverifikasie word verwerp nadat die tonnel bestaan. ’n Verwerpte rekening kan nie deur ’n NAT-beleidswysiging herstel word nie, en ’n voorstelverskil kan nie deur ’n herlaai herstel word nie.

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

’n Tydverstrekking sonder ’n reageerder dui op bereikbaarheid of filtering eerder as beleid. ’n Vinnige verwerping met ’n voorstelboodskap dui op algoritmes. ’n Mislukking nadat die tonnel op is, hoort by die verifikasiefase, wat ’n ander eienaar en ’n ander oplossing is.

SSTP oor HTTPS en inheemse IKEv2 het hul eie logs en hul eie kontroles. Niks daarvan word ’n NAT-traversal-saak net omdat hulle ook op Windows loop nie.

Maak die verandering met ’n terugweg

As die gedokumenteerde beleid en die waargeneemde topologie albei daarop dui, teken die vorige waarde op, pas die verandering toe deur die bestuurde konfigurasie eerder as ’n profielspesifieke script, en beplan die herstart. Op ’n bediener wat ander werkladings ondersteun, is dit nie ’n onskadelike wysiging nie.

Die NAT-toestel moet steeds die ingekapselde transport en die terugverkeer dra. ’n Registerwaarde skep geen aanstuuringsreël nie, belyn geen voorstelle nie en valideer geen identiteit nie, so ’n verbinding wat ná die verandering begin werk, kan om ’n heeltemal ander rede werk. Toets die oorspronklike protokol met die oorspronklike topologie weer, en skryf dan neer watter fase misluk het en waarom die waarde dit sou aanspreek. Daardie sin is wat ’n internetgerug in ’n verdedigbare konfigurasie omskep.