Windows-ийн NAT-T бүртгэлийн утга: эхлээд топологийг шалга

Windows VPN холболт бүтэлгүйтэж, хайлт бүртгэлийн утга буцааж, уг утга дахин ачаалалтын хамт оруулагдана. Энэ дараалал заримдаа ажилладаг бөгөөд хэзээ ч юу ч тайлбарладаггүй. Санаанд буй тохиргоо нь сервер NAT төхөөрөмжтэй харьцуулахад хаана байгаа тухай нэг асуултад хариулдаг бөгөөд аль протокол аль үе шатанд бүтэлгүйтсэнийг мэдэх хүртэл утгагүй.

Утга нь үнэндээ юу сонгодог вэ

AssumeUDPEncapsulationContextOnSendRule нь Windows-ийн IPsec хэрэгжилт NAT төхөөрөмжийн ард байгаа түнштэй холбоо тогтоохыг оролдох эсэхийг тодорхойлно. Баримтжуулсан өгөгдмөл 0 нь энэ тохиолдлыг зөвшөөрөхгүй, сервер NAT-ын ард байгаа тал байх үед 1 зөвшөөрнө, харин 2 нь хоёр үзүүрийг хоёуланг нь хөрвүүлэх тохиолдлыг хамарна. Эдгээр нь хэн хаана байгаа тухай топологийн мэдэгдэл юм.

Дараалал хэлбэрээр уншвал тоонууд улам их найдвартай байдлыг биш, улам их хөрвүүлэлтийг дүрсэлнэ. Юу ч хөрвүүлэгддэггүй сүлжээнд 2 тохируулах нь холболтыг хурдан эсвэл тогтвортой болгохгүй, нэвтрүүлэлтийн алдааг ч засахгүй. Microsoft-ын L2TP/IPsec-д зориулсан NAT удирдамж бодлого болон түүний түүхэн платформын нөхцөлийг баримтжуулна. Тэр нөхцөлийг таны бодитоор ажиллуулж буй Windows хувилбар, үүрэгтэй харьцуулан шалгаарай, учир нь хэд хэдэн хувилбарыг даван туулсан баримт бичиг нь одоогийн бүх build-ийн тухай мэдэгдэл биш.

Тооноос өмнө топологийг тааруул

Замыг зурж, хөрвүүлэлтийн цэгүүдийг тэмдэглэ: клиент гэрийн чиглүүлэгчийн ард байна уу, сервер ачааллын тэнцвэржүүлэгч эсвэл хаягийг дахин бичдэг галт хананы ард байна уу, аль нэг үзүүр таны хяналтад байхгүй операторын хөрвүүлэлтийн ард байна уу. Зөвхөн энэ зурсны дараа утга хэрэглэгдэх эсэх, аль үзүүрт хэрэглэгдэхийг шийдэж болно.

Одоогийн Windows Server хувилбарууд NAT traversal унтраалттайгаар зүгээр л ирдэг гэсэн мэдэгдэл үйлдэл хийхэд хэт өргөн юм. Чухал нь таны систем дэх бодлого, түүний өмнөх топологи, бүтэлгүйтсэн солилцоо — яг энэ дарааллаар. Хэрэв хоёр үзүүр хоёулаа нийтийн хаягтай бол тохиргоо таны асуудал биш. Үүний оронд саналыг, гэрчилгээг эсвэл бүртгэлийг харж, регистрийг орхи.

Эхлээд бүтэлгүйтлийн үе шатыг шалга

L2TP/IPsec дор хаяж гурван өөр бүтэлгүйтэл үүсгэдэг: түнш хүрэх боломжгүй, IPsec хамгаалалтыг тогтоох боломжгүй, мөн туннель үүссэний дараа PPP хэрэглэгчийн нэвтрүүлэлт татгалзагдана. Татгалзагдсан бүртгэлийг NAT бодлогыг өөрчлөхөд засахгүй, саналын зөрүүг дахин ачаалахад засахгүй.

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

Хариулагчгүй хугацаа дуусах нь бодлогыг бус хүртээмж эсвэл шүүлтийг илтгэнэ. Саналын зурвастай хурдан татгалзал нь алгоритмуудыг заана. Туннель боссны дараах бүтэлгүйтэл нь нэвтрүүлэлтийн үе шатанд хамаарах бөгөөд энэ нь өөр эзэмшигч, өөр шийдэл юм.

HTTPS дээрх SSTP болон уугуул IKEv2 нь өөрийн логи, өөрийн хяналттай. Windows дээр бас ажилладаг гэсэн шалтгаанаар аль нь ч NAT-traversal тохиолдол болохгүй.

Өөрчлөлтийг буцах замтайгаар хий

Хэрэв баримтжуулсан бодлого болон ажиглагдсан топологи хоёулаа үүнийг шаардвал өмнөх утгыг тэмдэглэ, өөрчлөлтийг профайл тус бүрийн скриптээр биш удирдлагатай тохиргоогоор хэрэгжүүл, дахин ачаалалтыг төлөвлө. Бусад ажлын ачааллыг дэмждэг сервер дээр энэ нь хор хөнөөлгүй засвар биш.

NAT төхөөрөмж инкапсуллагдсан тээвэр болон буцах урсгалыг хуучин хэвээр зөөх ёстой. Бүртгэлийн утга нь ямар ч дамжуулах дүрэм үүсгэхгүй, саналыг тааруулахгүй, ямар ч хэн болохыг баталгаажуулахгүй тул өөрчлөлтийн дараа ажиллаж эхэлсэн холболт огт өөр шалтгаанаар ажиллаж байж болно. Анхны топологитойгоо анхны протоколыг дахин туршиж, дараа нь аль үе шат бүтэлгүйтсэн, яагаад утга түүнийг шийднэ гэж хүлээсэн тухай бич. Яг энэ өгүүлбэр интернетийн цуурхалыг хамгаалж болох тохиргоо болгоно.