Windows NAT-T reģistra vērtība: vispirms pārbaudiet topoloģiju

Windows VPN savienojums neizdodas, meklēšana atgriež reģistra vērtību, un šī vērtība tiek ievadīta kopā ar pārstartēšanu. Šī secība dažkārt strādā un nekad neko neizskaidro. Attiecīgais iestatījums atbild uz vienu jautājumu par to, kur serveris atrodas attiecībā pret NAT ierīci, un tas ir bezjēdzīgs, līdz jūs zināt, kurš protokols un kurā posmā neizdevās.

Ko vērtība patiesībā izvēlas

AssumeUDPEncapsulationContextOnSendRule nosaka, vai Windows IPsec ieviešana mēģinās izveidot asociācijas ar partneri aiz NAT ierīces. Dokumentētā noklusējuma vērtība 0 neļauj šo gadījumu, 1 to ļauj, kad serveris ir aiz NAT esošā puse, un 2 aptver abu galu tulkošanu. Tie ir topoloģijas apgalvojumi par to, kurš kur atrodas.

Lasot kā secību, skaitļi apraksta arvien vairāk tulkošanas, nevis arvien lielāku uzticamību. Iestatījums 2 tīklā, kur nekas netiek tulkots, nepadara savienojumu ātrāku vai stabilāku un nelabo autentifikācijas kļūmi. Microsoft NAT norādījumi L2TP/IPsec dokumentē politiku un tās vēsturisko platformas kontekstu. Salīdziniet šo kontekstu ar Windows versiju un lomu, ko faktiski izmantojat, jo dokuments, kas pārdzīvojis vairākus laidienus, nav apgalvojums par katru pašreizējo būvējumu.

Saskaņojiet topoloģiju pirms skaitļa

Uzzīmējiet ceļu un atzīmējiet tulkošanas punktus: vai klients atrodas aiz mājas maršrutētāja, vai serveris atrodas aiz slodzes balansētāja vai ugunsmūra, kas pārraksta adreses, un vai kāds no galiem atrodas aiz operatora tulkošanas, ko jūs nevadāt. Tikai pēc šī zīmējuma varat izlemt, vai vērtība attiecas, un uz kuru galu.

Apgalvojums, ka pašreizējās Windows Server versijas vienkārši tiek piegādātas ar izslēgtu NAT traversal, ir pārāk plašs, lai pēc tā rīkotos. Svarīgi ir politika jūsu sistēmā, topoloģija tās priekšā un neizdevusies apmaiņa, tieši šādā secībā. Ja abiem galiem ir publiskas adreses, iestatījums nav jūsu problēma. Tā vietā aplūkojiet priekšlikumu, sertifikātu vai kontu un atstājiet reģistru mierā.

Vispirms pārbaudiet kļūmes posmu

L2TP/IPsec rada vismaz trīs dažādas kļūmes: partneris nav sasniedzams, IPsec aizsardzību nevar izveidot, un PPP lietotāja autentifikācija tiek noraidīta pēc tam, kad tunelis pastāv. Noraidītu kontu nevar salabot, mainot NAT politiku, un priekšlikumu nesaskaņu nevar salabot ar pārstartēšanu.

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

Taimauts bez atbildētāja norāda uz sasniedzamību vai filtrēšanu, nevis politiku. Ātrs noraidījums ar priekšlikuma ziņojumu norāda uz algoritmiem. Kļūme pēc tuneļa pacelšanas pieder autentifikācijas posmam, kas ir cits īpašnieks un cits risinājums.

SSTP pār HTTPS un vietējais IKEv2 ir ar saviem žurnāliem un savu pārvaldību. Nekas no tā nekļūst par NAT-traversal gadījumu tikai tāpēc, ka tie darbojas arī Windows.

Veiciet izmaiņas ar atgriešanās ceļu

Ja dokumentētā politika un novērotā topoloģija abas to prasa, pierakstiet iepriekšējo vērtību, piemērojiet izmaiņas, izmantojot pārvaldīto konfigurāciju, nevis skriptu katram profilam, un plānojiet pārstartēšanu. Serverī, kas atbalsta citas darba slodzes, tā nav nekaitīga rediģēšana.

NAT ierīcei joprojām jāpārvadā iekapsulētais transports un atgaitas plūsma. Reģistra vērtība neizveido nekādu pārsūtīšanas noteikumu, nesaskaņo priekšlikumus un nepārbauda identitāti, tāpēc savienojums, kas sāk darboties pēc izmaiņām, var darboties pavisam cita iemesla dēļ. Vēlreiz pārbaudiet sākotnējo protokolu ar sākotnējo topoloģiju, pēc tam pierakstiet, kurš posms neizdevās un kāpēc tika gaidīts, ka vērtība to atrisinās. Tieši šis teikums pārvērš interneta baumu konfigurācijā, kuru varat aizstāvēt.