Vrednost registra NAT-T v Windows: najprej preverite topologijo

Povezava VPN v Windows ne uspe, iskanje vrne vrednost registra in ta vrednost se vnese skupaj s ponovnim zagonom. To zaporedje včasih deluje in nikoli ničesar ne pojasni. Zadevna nastavitev odgovarja na eno vprašanje o tem, kje je strežnik glede na napravo NAT, in je brez pomena, dokler ne veste, kateri protokol in v kateri fazi je odpovedal.

Kaj vrednost dejansko izbere

AssumeUDPEncapsulationContextOnSendRule določa, ali bo izvedba IPsec v Windows poskušala vzpostaviti asociacije z partnerjem za napravo NAT. Dokumentirana privzeta vrednost 0 tega primera ne dovoljuje, 1 ga dovoljuje, ko je strežnik stran za NAT, in 2 pokriva prevajanje obeh koncev. To so izjave o topologiji — kdo je kje.

Če jih beremo kot zaporedje, številke opisujejo vse več prevajanja, ne vse večje zanesljivosti. Nastavitev 2 v omrežju, kjer se nič ne prevaja, povezave ne naredi hitrejše ali stabilnejše in ne popravi neuspeha preverjanja pristnosti. Smernice Microsofta za NAT pri L2TP/IPsec dokumentirajo politiko in njen zgodovinski kontekst platforme. Ta kontekst primerjajte z različico in vlogo Windows, ki ju dejansko izvajate, ker dokument, ki je preživel več izdaj, ni trditev o vsaki trenutni graditvi.

Najprej uskladite topologijo, nato število

Narišite pot in označite točke prevajanja: je odjemalec za domačim usmerjevalnikom, je strežnik za razporejevalnikom obremenitve ali požarnim zidom, ki prepisuje naslove, in je kateri od koncev za prevajanjem operaterja, ki ga ne nadzorujete. Šele po tej risbi se lahko odločite, ali vrednost velja, in za kateri konec.

Trditev, da so trenutne različice Windows Server preprosto dobavljene z izklopljenim NAT traversal, je preširoka, da bi lahko ukrepali na njeni podlagi. Pomembna je politika v vašem sistemu, topologija pred njim in izmenjava, ki je spodletela, v tem vrstnem redu. Če imata oba konca javne naslove, nastavitev ni vaša težava. Namesto tega poglejte predlog, potrdilo ali račun in register pustite pri miru.

Najprej preverite fazo neuspeha

L2TP/IPsec povzroči vsaj tri različne neuspehe: partner ni dosegljiv, zaščite IPsec ni mogoče vzpostaviti in preverjanje pristnosti uporabnika PPP se zavrne, ko tunel obstaja. Zavrnjenega računa ni mogoče popraviti s spremembo politike NAT, neujemanja predlogov pa ni mogoče popraviti s ponovnim zagonom.

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

Časovna omejitev brez odzivnika kaže na dosegljivost ali filtriranje, ne na politiko. Hitra zavrnitev s sporočilom o predlogu kaže na algoritme. Neuspeh po dvigu tunela spada v fazo preverjanja pristnosti, kar je drug lastnik in druga rešitev.

SSTP prek HTTPS in izvorni IKEv2 imata svoje dnevnike in svoj nadzor. Nič od tega ne postane primer NAT traversal samo zato, ker teče tudi v Windows.

Spremembo izvedite s potjo nazaj

Če dokumentirana politika in opažena topologija to zahtevata obe, zabeležite prejšnjo vrednost, spremembo uporabite prek upravljane konfiguracije in ne s skriptom za vsak profil, ter načrtujte ponovni zagon. Na strežniku, ki podpira druge delovne obremenitve, to ni neškodljivo urejanje.

Naprava NAT mora še vedno prenašati inkapsulirani promet in povratni promet. Vrednost registra ne ustvari nobenega pravila posredovanja, ne uskladi predlogov in ne preveri identitete, zato lahko povezava, ki po spremembi začne delovati, deluje iz povsem drugega razloga. Znova preizkusite izvirni protokol z izvirno topologijo, nato zapišite, katera faza je spodletela in zakaj naj bi vrednost to rešila. Ta stavek spremeni internetno govorico v konfiguracijo, ki jo lahko zagovarjate.