Windowsi NAT-T registriväärtus: kõigepealt kontrolli topoloogiat

Windowsi VPN-ühendus ebaõnnestub, otsing annab registriväärtuse ja väärtus sisestatakse koos taaskäivitusega. See jada mõnikord toimib ega selgita kunagi midagi. Kõnealune säte vastab ühele küsimusele selle kohta, kus server asub NAT-seadme suhtes, ja sellel pole mõtet enne, kui tead, milline protokoll ja millises etapis ebaõnnestus.

Mida väärtus tegelikult valib

AssumeUDPEncapsulationContextOnSendRule määrab, kas Windowsi IPsec-teostus üritab luua seoseid NAT-seadme taga oleva partneriga. Dokumenteeritud vaikeväärtus 0 ei luba seda juhtumit, 1 lubab seda, kui server on NAT-i taga olev pool, ja 2 katab mõlema otsa tõlkimise. Need on topoloogiaväljendid selle kohta, kes kus on.

Jadana lugedes kirjeldavad numbrid üha enam tõlkimist, mitte üha suuremat töökindlust. Väärtuse 2 seadmine võrgus, kus midagi ei tõlgita, ei muuda ühendust kiiremaks ega stabiilsemaks ega paranda autentimistõrget. Microsofti NAT-i juhend L2TP/IPsec jaoks dokumenteerib poliitika ja selle ajaloolise platvormikonteksti. Võrdle seda konteksti Windowsi versiooni ja rolliga, mida tegelikult kasutad, sest mitut väljaannet üle elanud dokument ei ole väide iga praeguse buildi kohta.

Sobita topoloogia enne numbrit

Joonista tee ja märgi tõlkepunktid: kas klient on koduruuteri taga, kas server on koormusjaoturi või aadresse ümber kirjutava tulemüüri taga, ja kas mõni ots on operaatori tõlkimise taga, mida sa ei kontrolli. Alles pärast seda joonistust saad otsustada, kas väärtus kehtib ja millise otsa jaoks.

Väide, et praegused Windows Serveri versioonid lihtsalt tarnitakse väljalülitatud NAT-traversaliga, on tegutsemiseks liiga lai. Tähtis on sinu süsteemi poliitika, selle ees olev topoloogia ja ebaõnnestunud vahetus, just selles järjekorras. Kui mõlemal otsal on avalikud aadressid, ei ole säte sinu probleem. Vaata selle asemel pakkumist, sertifikaati või kontot ja jäta register rahule.

Kontrolli kõigepealt tõrke etappi

L2TP/IPsec tekitab vähemalt kolm erinevat tõrget: partner ei ole kättesaadav, IPsec-kaitset ei saa luua ja PPP kasutaja autentimine lükatakse tagasi pärast tunneli olemasolu. Tagasi lükatud kontot ei paranda NAT-poliitika muutmine ja pakkumiste lahknevust ei paranda taaskäivitamine.

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

Vastajata aegumine viitab pigem kättesaadavusele või filtreerimisele kui poliitikale. Kiire tagasilükkamine pakkumisteatega osutab algoritmidele. Tõrge pärast tunneli püstitamist kuulub autentimise etapisse, mis on teine omanik ja teine parandus.

SSTP üle HTTPS-i ja natiivne IKEv2 on oma logide ja oma juhtimisvahenditega. Miski neist ei muutu NAT-traversali juhtumiks ainult sellepärast, et need töötavad ka Windowsis.

Tee muudatus tagasiteega

Kui dokumenteeritud poliitika ja vaadeldud topoloogia mõlemad seda nõuavad, kirjuta üles eelmine väärtus, rakenda muudatus hallatava konfiguratsiooni kaudu, mitte profiilipõhise skriptiga, ja planeeri taaskäivitus. Serveris, mis toetab muid töökoormusi, ei ole see kahjutu muudatus.

NAT-seade peab ikkagi kandma kapseldatud transporti ja tagastusliiklust. Registriväärtus ei loo ühtegi edastusreeglit, ei joonda pakkumisi ega valideeri identiteeti, seega võib ühendus, mis hakkab pärast muudatust tööle, töötada hoopis teisel põhjusel. Testi algne protokoll uuesti algse topoloogiaga ja kirjuta siis üles, milline etapp ebaõnnestus ja miks arvati, et väärtus selle lahendab. Just see lause muudab internetikuulujutu konfiguratsiooniks, mida saad kaitsta.