Halaga ng rehistro ng NAT-T sa Windows: tingnan muna ang topolohiya

Bumabagsak ang koneksyon ng VPN sa Windows, nagbabalik ng halaga ng rehistro ang isang paghahanap, at ipinapasok ang halagang iyon kasama ng pag-restart. Minsan gumagana ang pagkakasunod-sunod na iyon at kailanman ay walang naipapaliwanag. Ang setting na pinag-uusapan ay sumasagot sa isang tanong tungkol sa kung saan naroroon ang server kaugnay ng isang aparatong NAT, at wala itong kahulugan hangga't hindi mo alam kung aling protocol ang nabigo at sa aling yugto.

Ano talaga ang pinipili ng halaga

Tinutukoy ng AssumeUDPEncapsulationContextOnSendRule kung susubukan ng implementasyon ng IPsec sa Windows na gumawa ng mga asosasyon sa isang kapares sa likod ng aparatong NAT. Hindi pinapayagan ng dokumentadong default na 0 ang kasong iyon, pinapayagan ng 1 kapag ang server ang panig sa likod ng NAT, at sinasaklaw ng 2 ang pagsasalin ng dalawang dulo. Mga pahayag ito tungkol sa topolohiya—sino ang nasaan.

Kapag binasa bilang pagkakasunod-sunod, inilalarawan ng mga numero ang dumaraming pagsasalin, hindi ang dumaraming pagiging maaasahan. Ang pagtatakda ng 2 sa isang network kung saan walang isinasalin ay hindi ginagawang mas mabilis o mas matatag ang koneksyon, at hindi nito naaayos ang kabiguan sa pagpapatunay. Ang gabay ng NAT ng Microsoft para sa L2TP/IPsec ay nagdodokumento ng patakaran at ng makasaysayang konteksto nito sa plataporma. Ihambing ang kontekstong iyon sa bersyon at papel ng Windows na aktwal na pinapatakbo mo, dahil ang dokumentong nakaligtas sa ilang release ay hindi pahayag tungkol sa bawat kasalukuyang build.

Itugma ang topolohiya bago ang numero

Iguhit ang landas at markahan ang mga punto ng pagsasalin: nasa likod ba ng home router ang kliyente, nasa likod ba ng load balancer o firewall na nagre-rewrite ng mga address ang server, at nasa likod ba ng pagsasalin ng carrier na hindi mo kontrolado ang alinman sa mga dulo. Pagkatapos lamang ng guhit na iyon mo matutukoy kung naaangkop ang halaga, at sa aling dulo.

Ang pag-aangkin na ang mga kasalukuyang bersyon ng Windows Server ay basta dumarating na patay ang NAT traversal ay masyadong malawak para pagbasehan ng aksyon. Ang mahalaga ay ang patakaran sa iyong sistema, ang topolohiya sa harap nito at ang palitan na nabigo, sa ganoong pagkakasunod-sunod. Kung parehong may pampublikong address ang dalawang dulo, hindi mo problema ang setting. Tingnan ang panukala, sertipiko o account sa halip, at iwanan ang rehistro.

Tingnan muna ang yugto ng kabiguan

L2TP/IPsec ay nagdudulot ng hindi bababa sa tatlong magkakaibang kabiguan: hindi maabot ang kapares, hindi maitatag ang proteksyon ng IPsec, at tinatanggihan ang pagpapatunay ng user ng PPP pagkatapos na umiral ang tunnel. Hindi naaayos ang tinanggihang account sa pamamagitan ng pagbabago ng patakaran ng NAT, at hindi naaayos ang pagkakaiba ng mga panukala sa pamamagitan ng pag-restart.

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

Ang timeout na walang sumasagot ay nagpapahiwatig ng maabot o pagsasala kaysa patakaran. Ang mabilis na pagtanggi na may mensahe ng panukala ay tumuturo sa mga algorithm. Ang kabiguang pagkatapos ng pagtaas ng tunnel ay kabilang sa yugto ng pagpapatunay, na ibang may-ari at ibang solusyon.

Ang SSTP sa HTTPS at ang katutubong IKEv2 ay may sariling log at sariling kontrol. Wala sa mga ito ang nagiging kaso ng NAT-traversal dahil lamang tumatakbo rin ito sa Windows.

Gawin ang pagbabago na may daan pabalik

Kung hinihingi ng dokumentadong patakaran at ng naobserbahang topolohiya, itala ang dating halaga, ilapat ang pagbabago sa pamamagitan ng pinamamahalaang configuration at hindi ng script kada profile, at planuhin ang pag-restart. Sa server na sumusuporta sa iba pang workload, hindi ito walang pinsalang pag-edit.

Kailangan pa ring dalhin ng aparatong NAT ang naka-encapsulate na transport at ang trapikong pabalik. Walang nagagawang forwarding rule ang halaga ng rehistro, walang iniaayon na panukala at walang binibigyang-bisa na pagkakakilanlan, kaya ang koneksyon na nagsimulang gumana pagkatapos ng pagbabago ay maaaring gumagana sa lubos na ibang dahilan. Subukan muli ang orihinal na protocol sa orihinal na topolohiya, pagkatapos itala kung aling yugto ang nabigo at bakit inaasahang tutugunan iyon ng halaga. Ang pangungusap na iyon ang nagiging sanhi ng tsismis sa internet na maging configuration na maipagtatanggol mo.