Windows NAT-T-registerwearde: earst de topology besjen

In Windows-VPN-ferbining mislearret, in syktocht jout in registerwearde werom en de wearde wurdt mei in werstart ynfierd. Dy folchoarder wurket soms en ferklearret nea wat. De ynstelling dêr’t it om giet beantwurdet ien fraach oer wêr’t de tsjinner stiet ten opsichte fan in NAT-apparaat, en it is betsjuttingsleas oant jo witte hokker protokol mislearre en yn hokker stadium.

Wat de wearde eins kiest

AssumeUDPEncapsulationContextOnSendRule bepaalt oft in Windows-IPsec-ymplemintaasje assosjaasjes besykje sil mei in peet efter in NAT-apparaat. De dokumintearre standertwearde 0 lit dat gefal net ta, 1 lit it ta as de tsjinner de kant efter NAT is, en 2 beslacht dat beide einen oerset wurde. Dat binne topology-útspraken oer wa’t wêr is.

Lêzen as in folchoarder beskriuwe de sifers hieltyd mear oersetting, net hieltyd mear betrouberens. It ynstellen fan 2 op in netwurk dêr’t neat oerset wurdt, makket de ferbining net flugger of stabiler en reparearret ek gjin autentikaasjeflater. De NAT-rjochtline fan Microsoft foar L2TP/IPsec dokumintearret it belied en syn histoaryske platfoarmkontekst. Hâld dy kontekst tsjin de Windows-ferzje en -rol oan dy’t jo eins draaie, want in dokumint dat ferskate releases oerlibbe hat, is gjin útspraak oer elke hjoeddeiske build.

Pas de topology oan foar it nûmer

Tekenje it paad en markearje de oersettingspunten: sit de klant efter in thúsrouter, sit de tsjinner efter in load balancer of in firewall dy’t adressen oerskriuwt, en sit ien fan ’e einen efter in ferfierdersoersetting dy’t jo net kontrolearje. Pas nei dy tekening kinne jo beslute oft de wearde jildt en foar hokker ein.

De bewearing dat hjoeddeiske Windows Server-ferzjes gewoan mei útskeakele NAT-traversal levere wurde, is te breed om op te hanneljen. Wat telt is it belied op jo systeem, de topology dêrfoar en de útwikseling dy’t mislearre, yn dy folchoarder. As beide einen iepenbiere adressen hawwe, is de ynstelling net jo probleem. Sjoch ynstee nei it foarstel, it sertifikaat of it akkount, en lit it register gewurde.

Kontrolearje earst it stadium fan ’e flater

L2TP/IPsec jouwt op syn minst trije ferskillende flaters: de peet is net berikber, IPsec-beskerming kin net fêstige wurde, en de PPP-brûkersautentikaasje wurdt ôfwiisd nei’t de tunnel bestiet. In ôfwiisd akkount kin net reparearre wurde troch NAT-belied te feroarjen, en in foarstelôfwiking kin net reparearre wurde troch opnij te starten.

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

In time-out sûnder antwurdjouwer suggerearret berikberens of filterjen ynstee fan belied. In flugge ôfwizing mei in foarstelberjocht wiist op algoritmen. In flater nei’t de tunnel omheech is, heart by it autentikaasjestadium, dat is in oare eigner en in oare oplossing.

SSTP oer HTTPS en native IKEv2 hawwe har eigen logs en har eigen kontrôles. Neat dêrfan wurdt in NAT-traversal-gefal allinnich om’t se ek op Windows draaie.

Doch de feroaring mei in weromwei

As it dokumintearre belied en de waarnommen topology beide dêrom freegje, skriuw de foarige wearde op, pas de feroaring ta fia de behearde konfiguraasje en net fia in skript per profyl, en plan de werstart. Op in tsjinner dy’t oare workloads stipet, is dit gjin ûnskuldige bewurking.

It NAT-apparaat moat noch altyd it ynkapsulearre ferfier en it weromferkear drage. In registerwearde makket gjin trochstjoerregel, rjochtet gjin foarstellen ôf en falidearret gjin identiteit, dus in ferbining dy’t nei de feroaring begjint te wurkjen, kin om in hiel oare reden wurkje. Test it oarspronklike protokol opnij mei de oarspronklike topology, en skriuw dan op hokker stadium mislearre en wêrom’t de wearde dat oplosse soe. Dy sin is wat in ynternetgermoed ta in konfiguraasje makket dy’t jo ferdigenje kinne.