Windows NAT-T-registerwaarde: kijk eerst naar de topologie

Een Windows-VPN-verbinding mislukt, een zoekopdracht levert een registerwaarde op en die waarde wordt samen met een herstart ingevoerd. Die volgorde werkt soms en verklaart nooit iets. De instelling in kwestie beantwoordt één vraag over waar de server staat ten opzichte van een NAT-apparaat, en ze is zinloos tot je weet welk protocol in welke fase faalde.

Wat de waarde werkelijk selecteert

AssumeUDPEncapsulationContextOnSendRule bepaalt of een Windows-IPsec-implementatie associaties met een peer achter een NAT-apparaat zal proberen op te zetten. De gedocumenteerde standaardwaarde 0 staat dat geval niet toe, 1 staat het toe wanneer de server de kant achter NAT is, en 2 dekt dat beide uiteinden worden vertaald. Dat zijn topologieverklaringen over wie waar staat.

Als reeks gelezen beschrijven de getallen steeds meer vertaling, niet steeds meer betrouwbaarheid. De waarde 2 instellen op een netwerk waar niets wordt vertaald maakt de verbinding niet sneller of stabieler en repareert geen verificatiefout. Microsofts NAT-richtlijn voor L2TP/IPsec documenteert het beleid en de historische platformcontext ervan. Leg die context naast de Windows-versie en -rol die je werkelijk draait, want een document dat meerdere releases heeft overleefd is geen uitspraak over elke huidige build.

Stem de topologie af vóór het nummer

Teken het pad en markeer de vertaalpunten: staat de client achter een thuisrouter, staat de server achter een load balancer of een firewall die adressen herschrijft, en ligt een van de uiteinden achter providervertaling die je niet beheert. Pas na die tekening kun je beslissen of de waarde van toepassing is, en op welk uiteinde.

De bewering dat huidige Windows Server-versies gewoon met NAT-traversal uitgeschakeld worden geleverd is te breed om op te handelen. Wat telt is het beleid op je systeem, de topologie ervoor en de uitwisseling die faalde, in die volgorde. Als beide uiteinden openbare adressen hebben, is de instelling niet jouw probleem. Kijk in plaats daarvan naar het voorstel, het certificaat of het account, en laat het register met rust.

Controleer eerst de faalfase

L2TP/IPsec levert minstens drie verschillende fouten op: de peer is onbereikbaar, IPsec-bescherming kan niet tot stand worden gebracht, en de PPP-gebruikersverificatie wordt geweigerd nadat de tunnel bestaat. Een geweigerd account laat zich niet repareren door NAT-beleid te wijzigen, en een voorstelverschil laat zich niet repareren door te herstarten.

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

Een time-out zonder responder wijst op bereikbaarheid of filtering eerder dan op beleid. Een snelle weigering met een voorstelbericht wijst op algoritmen. Een fout nadat de tunnel staat hoort bij de verificatiefase, dat is een andere eigenaar en een andere oplossing.

SSTP over HTTPS en native IKEv2 hebben hun eigen logboeken en hun eigen controles. Niets daarvan wordt een NAT-traversal-geval alleen omdat ze ook op Windows draaien.

Voer de wijziging uit met een weg terug

Als het gedocumenteerde beleid en de waargenomen topologie er beide om vragen, noteer dan de vorige waarde, pas de wijziging toe via de beheerde configuratie en niet via een script per profiel, en plan de herstart. Op een server die andere workloads ondersteunt is dit geen onschuldige bewerking.

Het NAT-apparaat moet het ingekapselde transport en het retourverkeer nog steeds dragen. Een registerwaarde maakt geen doorstuuregel, lijnt geen voorstellen uit en valideert geen identiteit, dus een verbinding die na de wijziging begint te werken kan om een heel andere reden werken. Test het oorspronkelijke protocol opnieuw met de oorspronkelijke topologie en schrijf dan op welke fase faalde en waarom de waarde dat zou oplossen. Die zin is wat een internetgerucht verandert in een configuratie die je kunt verdedigen.