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

Ei Windows VPN-tilkopling feilar, eit søk returnerer ein registerverdi, og verdien blir lagd inn saman med ein omstart. Den sekvensen verkar nokre gonger og forklarar aldri noko. Innstillinga det gjeld, svarar på eitt spørsmål om kvar tenaren står i høve til ein NAT-eining, og ho er meiningslaus til du veit kva protokoll som feila og i kva fase.

Kva verdien eigentleg vel

AssumeUDPEncapsulationContextOnSendRule avgjer om ein Windows-IPsec-implementasjon vil prøve å opprette assosiasjonar med ein part bak ei NAT-eining. Standardverdien 0 tillèt ikkje det tilfellet, 1 tillèt det når tenaren er sida bak NAT, og 2 dekkjer at begge endar blir omsette. Dette er topologiutsegner om kven som er kvar.

Lese som ein sekvens skildrar tala stadig meir omsetjing, ikkje stadig større pålitelegheit. Å setje 2 på eit nett der ingenting blir omsett gjer ikkje tilkoplinga raskare eller meir stabil, og det reparerer ikkje ein autentiseringsfeil. Microsoft si rettleiing om NAT for L2TP/IPsec dokumenterer policyen og den historiske plattformkonteksten hans. Hald den konteksten opp mot Windows-versjonen og -rolla du faktisk køyrer, for eit dokument som har overlevd fleire utgjevingar er ikkje ei utsegn om kvar noverande build.

Tilpass topologien før talet

Teikn banen og merk omsetjingspunkta: sit klienten bak ein heimeruttar, sit tenaren bak ein lastbalansar eller ein brannmur som skriv om adresser, og ligg ein av endane bak ei operatørbasert omsetjing du ikkje styrer. Først etter den teikninga kan du avgjere om verdien gjeld, og for kva ende.

Påstanden om at noverande Windows Server-versjonar berre blir leverte med NAT-traversering deaktivert er for brei å handle etter. Det som tel, er policyen på systemet ditt, topologien framfor det og utvekslinga som feila, i den rekkjefølgja. Viss begge endar har offentlege adresser, er innstillinga ikkje problemet ditt. Sjå i staden på framlegget, sertifikatet eller kontoen, og lat registeret vere.

Kontroller feilfasen først

L2TP/IPsec gir minst tre ulike feil: parten er ikkje nåbar, IPsec-vern kan ikkje etablerast, og PPP-brukarautentisering blir avvist etter at tunnelen finst. Ein avvist konto kan ikkje reparerast ved å endre NAT-policy, og eit framleggsavvik kan ikkje reparerast 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

Ein tidsavbrot utan svar tyder på nåbarheit eller filtrering snarare enn policy. Ei rask avvising med ei framleggsmelding peikar på algoritmar. Ein feil etter at tunnelen er oppe, høyrer til autentiseringsfasen, som er ein annan eigar og ei anna løysing.

SSTP over HTTPS og innebygd IKEv2 har eigne loggar og eigne kontrollar. Ingenting av det blir ei NAT-traverseringssak berre fordi dei òg køyrer på Windows.

Gjer endringa med ein veg tilbake

Viss den dokumenterte policyen og den observerte topologien begge krev det, noter den førre verdien, bruk endringa via den styrte konfigurasjonen i staden for eit skript per profil, og planlegg omstarten. På ein tenar som støttar andre arbeidslaster er dette ikkje ei uskuldig endring.

NAT-eininga må framleis bere den innkapsla transporten og returtrafikken. Ein registerverdi lagar inga vidaresendingsregel, justerer ikkje framlegg og validerer ikkje identitet, så ei tilkopling som byrjar å verke etter endringa kan verke av ein heilt annan grunn. Test den opphavlege protokollen med den opphavlege topologien på nytt, og skriv deretter ned kva fase som feila og kvifor verdien var venta å løyse det. Den setninga er det som gjer eit internettrykte til ein konfigurasjon du kan forsvare.