Azure P2S VPN-ийн буцах трафик зөвхөн нэг чиглэлд ажилладаг

Туннелийн дүрс ногоон, NSG зөвшөөрч байгаа мэт харагдана, үр дүнтэй маршрутууд зөв харагдана, гэвч VM холбогдсон клиент рүү буцах холболт нээж чадахгүй хэвээр байна. Ердийн таамаглал нь ажиллаж буй point-to-site туннель тэгш хэмжээтэй: клиент VM-д хүрвэл VM ч клиентэд хүрнэ. Тэр таамаглал нь тохиргооны биш, сэтгэлгээний алдаа юм. Туннель хүсээгүй урсгалын нэг чиглэлийг зөөж, нөгөөг нь хаяж болох бөгөөд засвар нь алийн давхарга үүнийг хаяж байгаагаас хамаарна.

Домог: холбогдсон туннель бол хоёр чиглэлийн туннель

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

Практикт тэгш бус байдал маш түгээмэл тул чиглэлийг сүүлийн биш, эхний шалгалтад оруулах ёстой. Клиент эхлүүлж, гарц урсгалыг дагаж, хариу нь үүссэн төлөвд дагадаг. Шинэ урсгал эхлүүлж буй VM-д ийм төлөв байхгүй тул буцах зам тодорхой маршрутлагдахуйц, зөвшөөрөгдсөн байх шаардлагатай. Тэр зам байхгүй бол холболтын оролдлого аль ч програмын харахаас өмнө үхдэг.

Хүртээмжийг шалгахаас өмнө чиглэлийг шалгана уу

Нэг клиентийн хаяг, нэг VM хаяг, нэг протокол сонгоно уу. Клиентээс холбогдоод үр дүнг бичнэ үү; дараа нь мөн адил шалгалтыг VM-ээс эхлүүлж, түүнийг ч бичнэ үү. Эхнийх нь амжилттай, хоёр дахь нь бүтэлгүй бол клиентийн сан, гарцын холбоо, клиентээс VNet хүртэлх зам бүгд ажиллаж байна.

Дараагийн алхам бол нотолгоо, илүү дүрэм биш. VM-ийн дэд сүлжээн дэх NSG-г хоёр чиглэлд шалгаж, VM-ийн NIC дээрх үр дүнтэй маршрутуудыг уншиж, клиент трафик илгээж байх үед VM дээр пакет барьж авна уу. Хариугүй ирсэн хүсэлт нь шүүлтүүр эсвэл буцах маршрутын асуудал; огт ирээгүй хүсэлт нь замын асуудал. Бүтэлгүй ping-ийг VM хүртээмжгүй гэсэн нотолгоо гэж бүү үз, учир нь TCP ажиллаж байхад ICMP бодлого хариуг хаяж болно.

IKEv2 point-to-site буцах зам бол ердийн сэжигтэн

Энэ өгүүллийн үндэс болсон Azure тайланд клиент IKEv2-оор VM-д хүрч байсан ч VM-ээс клиент рүү ирэх ICMP нь гарцын туннелийн төрлийг OpenVPN руу солих хүртэл бүтэлгүй байв. Тайлангийн зохиолч Microsoft IKEv2 point-to-site замд хязгаарлалтыг баталгаажуулсан гэж мэдэгдэв: хэрэв сессийг клиент эхлүүлээгүй бол VM-ээс клиент рүү буцах трафик тэгш хэмжээр маршрутлагдахгүй. IKEv2 трафикийн селекторуудад тулгуурладаг бөгөөд гарц тэр тохиолдолд буцах чиглэлийг хүндэтгээгүй.

Энэ нь OpenVPN-ийг ерөнхийдөө илүү сайн туннелийн төрөл болгодоггүй. Энэ нь туннелийн төрлийг энэ ажлын ачааллын шалгалтын матрицад хувьсагч болгодог.

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

Домог: broadcast-аар илрүүлэх нь VNet-ийн хилээр гардаг

Хоёр дахь таамаглал нь хамааралгүй шалтгаанаар бүтэлгүйтдэг. Azure виртуал сүлжээ broadcast трафикийг зөөдэггүй тул VM site-to-site эсвэл point-to-site холболтоор байршлын сүлжээнээс broadcast фрейм хүлээж авах боломжгүй. Broadcast-аар хамтрагчдаа олдог програмууд, жишээ нь хуучин файл хөтлөх эсвэл зарим төхөөрөмж илрүүлэх протоколууд, маршрутуудыг хэрхэн бичсэнээс үл хамааран алслагдсан талыг хэзээ ч харахгүй.

Broadcast-аар илрүүлэхийг DNS нэр, лавлах үйлчилгээ эсвэл тодорхой хамтрагчийн жагсаалтаар солино уу. Хэрэв програмд unicast хувилбар байхгүй бол загварт илүү өргөн туннель биш, өөр илрүүлэх механизм хэрэгтэй.

Юу өөрчлөх, үүнийг хэрхэн батлах

Хэрэв чиглэлийн шалгалт зөвхөн IKEv2 дээр бүтэлгүй бол гарцын туннелийн төрөл, клиентийн хаягийн сан, яг ICMP эсвэл TCP шалгалтыг бичээд, дараа нь нөлөөлөгдсөн клиентүүдэд зөвшөөрсөн OpenVPN профайлыг үнэлнэ үү. Хэрэв бүх туннелийн төрөл дээр бүтэлгүй бол буцах замаар ажиллана уу: клиентийн хаяг VM-ийн дэд сүлжээнээс маршрутлагдах боломжтой байх ёстой, хэрэглэгчийн тодорхойлсон аливаа маршрут хүчинтэй дараагийн алхам руу заах ёстой, клиентийн галт хана ирж буй урсгалыг хүлээн авах ёстой. NSG болон маршрутын нотолгоог тасагт хавсаргана уу.

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