NAT-аар дамжсан L2TP/IPsec: юу үнэхээр эвдэрч, яагаад

NAT L2TP/IPsec-г эвддэг гэсэн мэдэгдэл хагас үнэн тул хэрэггүй. Хаягийн хөрвүүлэлт хэвийн зүйл, NAT traversal яг түүнийг даван туулахын тулд байдаг бөгөөд өдөр бүр олон сая клиент маршрутизаторын ардаас холбогддог. Эвдэрдэг зүйл бол тодорхой солилцооны тодорхой үе шат: IKE хэзээ ч хариу авдаггүй, капсуллагдсан туннелийг зөвхөн нэг протокол зөвшөөрдөг бодлогоор хаядаг, эсвэл туннель сул зогсож байхад хөрвүүлэлтийн mapping дуусдаг. Аль үе шатанд байгаагаа мэдсэний дараа засвар нь ихэвчлэн нэг дүрэм эсвэл keepalive, шинэ VPN дизайн биш.

Домог бол буруу асуулт

Хэрэгтэй асуулт нь «NAT үүнийг эвдэх үү» биш, харин «солилцооны аль хэсэг хөрвүүлэгдэж, хөрвүүлж буй төхөөрөмж түүнтэй юу хийдэг». L2TP/IPsec нь давхаргат протокол: IKE хэлэлцээр хийдэг, ESP хамгаалдаг, харин L2TP тэр хамгаалалтын дотор PPP зөөдөг. Хаягийн хөрвүүлэлт давхарга бүрт өөрөөр нөлөөлдөг бөгөөд алдааны цонх биш хэлэлцээрийн үе шатыг харвал алдааны шинж тэмдгийг ялгаж болно.

Вэбийг амжилттай үздэг маршрутизатор эх портын хөрвүүлэлттэй TCP ажиллаж байгааг л батална. Энэ нь UDP 500, UDP 4500 эсвэл 50 протоколын талаар юу ч хэлэхгүй бөгөөд энэхүү байршуулалт яг тэр гуравт тулгуурладаг.

1-р үе шат: IKE ямар ч байсан хариу авах ёстой

Эхний солилцоо UDP 500 дээр хариулагч руу явдаг. Хариу буцаж ирэхгүй бол бусад бүх зүйл хамаагүй: урьдчилан хуваалцсан түлхүүр, санал, нэвтрэх мэдээлэл бүгд уншигдаагүй үлддэг. Клиентийн тайм-аутаас дүгнэх биш, хүсэлт болон хариуг ажиглаарай:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

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

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

2-р үе шат: капсулалт firewall-ын хардаг зүйлийг өөрчилдөг

ESP бол IP протокол, TCP эсвэл UDP порт биш бөгөөд энгийн портын хаягийн хөрвүүлэлтэд дахин бичих портын талбар байхгүй. Тиймээс NAT traversal хамгаалагдсан ачааг UDP 4500 руу зөөдөг: капсулалт нь хөрвүүлж буй төхөөрөмжид хэрхэн хөрвүүлэхээ мэддэг зүйлийг өгдөг. Ингэсний дараа зөвхөн UDP 500-д зориулж бичсэн firewall дүрэм хэлэлцээрийг зөвшөөрч, туннелийг хаях бөгөөд энэ нь лог амжилттай 1-р фаз болон ямар ч хөдөлгөөнгүйг харуулах будлиантай үр дүнг үүсгэдэг.

IKE солилцоо өөрөө ч NAT илэрсний дараа UDP 4500 руу шилжиж болох бөгөөд энэ нь зөвхөн 500-г зөвшөөрсөн хүмүүсийг гайхшруулдаг. Зам дээр хоёр портыг хоёр чиглэлд зөвшөөр, мөн төлөвтэй firewall урсгалыг зөвхөн хөдөлгөөн харж байгаа дотор нь барина гэдгийг сана.

50 протокол нь хөрвүүлэлтгүй зам болон завсрын хайрцаг түүнийг зөвшөөхөөр тохируулагдсан зам дээр чухал хэвээр. Хэрэв хасаж оношилгоо хийдэг бол дүрмүүдийг бөөнөөр нэмэхийн оронд таамаглалыг унтраа: 500, 4500, ESP-г зөвшөөрч, туннель босч байгааг баталж, дараа нь илүүдэл болсон зүйлийг хас. Хэн ч тайлбарлаж чадахгүй дүрэм бол дараагийн тасалдлын шалтгаан болоход хэн ч арилгахгүй дүрэм юм. Нарийсгалыг өөрчилсөн үе шаттайгаа хамт өөрчлөлтийн бүртгэлд бич, дараагийн инженер ижил эрхий дүрмээс биш, чиний нотолгооноос эхлэх болтугай.

3-р үе шат: mapping дуусч, туннель үхдэг

Хөрвүүлж буй төхөөрөмж дамжуулж буй урсгалуудад төлөв хадгалдаг бөгөөд тэр төлөв нь амьдрах хугацаатай. L2TP/IPsec туннель хэн ч ашиглахгүй үед бага хөдөлгөөн зөөдөг тул сул зогссон туннель mapping-аасаа урт амьдарч, буцах хөдөлгөөн авахаа болино. Клиент холбогдсон гэдэгтээ итгэлтэй хэвээр, сервер юу ч хардаггүй, эхний шинж тэмдэг нь ихэвчлэн VPN алдаа биш, програмын тайм-аут юм.

Үхсэн түншийг илрүүлэх болон NAT keepalive нь үүний төлөө байдаг бөгөөд хоёр төгсгөл илгээхэд бэлэн байх ёстой. Хэрэв сервер чинь хөрвүүлэлтийн ард байвал Windows талын шаардлага нь серверийг өөрийн гарч буй пакетуудад UDP капсулалт гэж үзүүлэх баримтжуулсан бүртгэлийн тохиргоо юм; үүнгүйгээр хариулагч нь хөрвүүлж буй төхөөрөмж буцааж mapping хийж чадахгүй ESP илгээдэг. Энэ нь серверийн тохиргооны асуудал, клиентийн биш.

WAN хаяг өөрчлөгдөх нь нөгөө талаас ижил үр дүн өгнө: mapping шинэ хаягийн эргэн тойронд дахин бүтээгдэж, хуучин аюулгүй байдлын холбоо одоо байхгүй хос руу заана. Дахин холбогдох зан төлөв нь клиентийн хэрэгжүүлэлтэд хамаарах бөгөөд иймээс «маршрутизатор дахин асасны дараа дахин холбогд» нэг клиент дээр ажиллаж, нөгөө дээр гараар шилжүүлэгч шаарддаг.

Операторын түвшний NAT-ын ард хостинг хийх нь өөр асуудал

Хэрэв гэртээ L2TP/IPsec серверийг хостинг хийж, гаднаас нь хүрэхийг хүсвэл шаардлага нь хүсээгүй орж ирэх хүртээмж бөгөөд NAT traversal үүнийг өгдөггүй. Маршрутизаторын чинь өмнө операторын түвшний NAT байгаа нь нийтийн хаяг хуваалцагддаг, mapping нь зөвхөн гардаг тул чамайг хүртээмжтэй болгох шилжүүлж болох порт байхгүй гэсэн үг.

Ямар ч IPsec pass-through нүд өөрчлөхгүй, ямар ч клиентийн тохиргоо нөхөхгүй. Дэмжигдсэн хариултууд нь үнэхээр хүртээмжтэй хаяг, хостинг хийсэн төгсгөлийн цэг, эсвэл оролцогч бүр гарч буй холболт хийдэг архитектур юм. UDP капсулалтын тодорхойлолт нь одоо байгаа урсгалуудад хөрвүүлэлтийн асуудлыг шийддэг; оператор санал болгодоггүй газар орж ирэх зам үүсгэдэггүй.

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