Azure P2S VPN дахь статик IP: клиентийн хаяг яагаад өөрчлөгддөг вэ

Azure point-to-site-ийн клиент бүр баталгаажуулалтын үед сангаас хаяг авч, зөвхөн тэр холболт үргэлжлэх хугацаанд хадгална. Нөөцлөлтийн хүснэгт ч, хэрэглэгч тус бүрийн зураглал ч, „энэ хүнд үргэлж 172.16.0.10 өг“ гэсэн утгатай гарцын тохиргоо ч байхгүй. Яг энэ нэг механизм нь хүмүүсийн дараа тулгардаг хоёр шинж тэмдгийг тайлбарладаг: өмнө нь тохирч байсан хэрэглэгчтэй одоо тохирохгүй болсон NSG дүрэм, мөн хэн ч санаатайгаар нэмээгүй машиныг чимээгүй нэвтрүүлдэг зөвшөөрлийн жагсаалт. Дүрмийг илүү ухаалаг IP дүрмээр солих нь аль алиныг нь засдаггүй, учир нь дүрмийн нэрлэдэг зүйл таны хянадаггүй хуваарийн дагуу дахин хуваарилагддаг.

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

Клиент холбогдоход гарц үнэндээ юу хийдэг вэ

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

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

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

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

Клиентийн IP-д суурилсан NSG нь үнэндээ холболтын дарааллын тухай дүрэм

Хүмүүсийн хамгийн түрүүнд бичдэг дүрэм нь илэрхий: удирдлагын VM-ийн NIC эсвэл түүний дэд сүлжээнд орох дүрэм, эх сурвалж нь VPN клиентийн дотоод хаяг. Богино, бичсэн өдрөө тестийг давж, санд нэгээс олон чөлөөт хаяг байх үед тэр даруй бүтэлгүйтдэг.

Үүнээс хоёр бүтэлгүйтлийн хэлбэр гарч, зөвхөн нэг нь алдаа мэт харагддаг. Хууль ёсны хэрэглэгчид татгалздаг, учир нь дүрмийн нэрлэсэн хаягийг тухайн мөчид өөр хэн нэгэн барьж байна, энэ нь төвөгтэй дэмжлэгийн тасалбар болж ирдэг. Эсвэл санаандгүй хэрэглэгчийг нэвтрүүлдэг, учир нь тэр дүрэм одоо ч итгэдэг хаягийг өвлөсөн, энэ нь хэн нэгэн хандалтыг аудит хийх хүртэл юу ч мэт ирдэггүй.

Дүрэм түрээсийг дагадаг тул бодит бодлого нь „хамгийн түрүүнд холбогдсон хүн удирдлагын хандалт авна“ гэж уншигдана. Энэ бол санааны хувцас өмссөн холболтын дарааллын тайлбар бөгөөд ямар ч дүрмийн эрүүл ахуй үүнийг санааны илэрхийлэл болгодоггүй.

Клиентийн түрээс ба гарцын хаяг нь өөр өөр объект

Төөрөгдлийн ихэнх нь нэг үгнээс гардаг. Гарц харьцангуй тогтвортой нийтийн IP-тэй; клиентүүд сангаас авсан хувийн хаягтай бөгөөд тэдгээр нь тогтвортой биш. Бүс нутгийн нөөцлөлтгүй VPN гарцын нийтийн IP динамикаар олгогддог ч хэмжээ өөрчлөлт, дахин ачаалт, ердийн засвар үйлчилгээг даван туулдаг — гарц өөрөө устгагдаж дахин үүсэх үед л өөрчлөгддөг. Бүс нутгийн нөөцлөлттэй болон бүсийн гарцын SKU нь Standard SKU-ийн нийтийн IP ашигладаг бөгөөд энэ олголт статик байх ёстой.

Энэ тогтвортой байдал нь орон нутгийн түншийн тохиргоонд хэрэгтэй зүйл бөгөөд ганц клиентийг таних тухай юу ч хэлдэггүй. Түнш ямар хаяг харахыг асуухад хариулт нь site-to-site үеийн гарцын нийтийн IP эсвэл хуваалцсан NAT хүрээ — хэзээ ч зөөврийн компьютерийн туннелийн түрээс биш.

Бүлгийн сангууд танд дүрэм бичихэд үнэ цэнэтэй хүрээ өгдөг

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

Үүссэн дүрмийн багц нь хянаж болох хэлбэртэй:

• аудитор бүрт нэг сан, толгойн тоо биш харин зэрэгцээ сессийн оргилд тохируулсан;
• бүлгийн гишүүнчлэл таних тэмдгээр удирдагдана, хэн нэгэн нэгдэх бүрт дүрэм засварладаггүй;
• NSG эсвэл Azure Firewall дүрмүүд сангийн хүрээний эсрэг бичигдэнэ, хэзээ ч ганц түрээсийн эсрэг биш;
• хүрээг хэзээ ч хуваалцах ёсгүй аудиторт зориулсан тусдаа зангилаа эсвэл гарц.

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

Байршуулалт Virtual WAN руу шилжиж чадахгүй үед

Олон гарц энгийн VPN гарц хэвээр үлддэг бөгөөд Virtual WAN руу шилжих нь санамсаргүй өөрчлөлт биш. Практик хариулт нь хэрэглэгч тус бүрийн шийдвэрийг багц шүүлтүүрээс хэрэглэгч хэн болохыг аль хэдийн мэддэг зүйл рүү шилжүүлэх юм.

Нөөцийн түвшний таних тэмдэг нь хамгийн хямд хувилбар. Storage, SQL, Key Vault бүгд хэрэглэгч эсвэл бүлгээр дүр олголттой Entra ID баталгаажуулалтыг дэмждэг тул VPN зөвхөн сүлжээний хүртээмжийг нотлох хэрэгтэй. Нэртэй бүртгэл бүхий үсрэх хост нь захиргааны ажилд ижил үүрэг гүйцэтгэдэг, учир нь хост хүнийг бүртгэж, туннель зөвхөн багц зөөдөг. Клиентүүдийг DNS-д бүртгэж, тооны оронд нэрийг зөвшөөрөх нь дүрмийг нэг давхарга өргөдөг. Аппликейшны түвшний таних тэмдэг — гэрчилгээний субъект, токены мэдэгдэл, бүлгийн гишүүнчлэл — шийдэхэд сүлжээг биш, аппликейшныг асуух үед ажилладаг.

Тогтмол эх хаяг шаарддаг түншид хариулт нь тодорхойлогдсон түншийн префикстэй site-to-site эсвэл ExpressRoute юм. Тэд түншийн префиксийг зөвшөөрдөг, тэдний талд харагдах хаяг нь гарцад хамаарах бөгөөд хэн нэгэн зөөврийн компьютер дахин ачаалахад өөрчлөгддөггүй.

Дараагийн зөвшөөрлийн жагсаалтыг засахын өмнө санг шалгана уу

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

Дүрэмд хүрэхийн өмнө гурван зүйлийг нэг хуудсанд байрлуул: point-to-site сан, виртуал сүлжээний хаягийн орон зай, орон нутгийн хүрээ. Тэд давхцах ёсгүй бөгөөд санд зэрэгцээ клиент бүрт зай, дахин холболтод зай хэрэгтэй.

Дараа нь циклийг энэ дарааллаар хаа:

• Хоёр машинаас хоёр дарааллаар холбогдож хаягуудыг харьцуул; хэрэв тэд солигдож чадвал хаягт суурилсан ямар ч дүрэм аюулгүй биш.
• Гарц Virtual WAN мөн эсэхийг шалга; тийм бол хаяг тус бүрийн дүрмийн оронд бүлгийн сангуудыг ашигла.
• Дүрэм буруу хүнд тохиолдоход юу болохыг асуу; хариулт нь хандалтын осол бол хяналтыг таних тэмдэг рүү шилжүүл.
• Аль хүрээ аль бүлэгт хамаарахыг NSG тодорхойлолттой ижил агуулахад бич.
• Сан, баталгаажуулалт эсвэл гарцын аливаа өөрчлөлтийн дараа дахин шалга, учир нь тэдгээр өөрчлөлт зураглалыг зарлалгүйгээр дахин бичдэг.