Peering-ээр холбогдсон Azure VNet-д өөрийн VPN гарц хэрэгтэй юу?
Peering-ээр холбогдсон VNet нь дэмжигдсэн SKU болон peering-ийн чиглэл бүрт нэг тохиргоогоор hub-ийн VPN гарцыг ашиглаж болно. Peering-ийн төлөвөөр биш, үр дүнтэй маршрутаар шалгаарай.
Шинэ spoke VNet гарч ирж, hub-д аль хэдийн ажиллаж буй site-to-site гарц байна, тэгэхээр хоёр дахь гарцын төлбөр төлөх шаардлагатай эсэх нь ойлгомжтой асуулт юм. Ихэвчлэн үгүй: гарцын дамжуулалт нь spoke-д peering-ээр дамжуулан hub-ийн гарцыг ашиглах боломж олгодог. Энэ ажиллах эсэхийг гурван нөхцөл шийддэг бөгөөд тэдгээрийн аль нь ч peering-ийн төлөвийн тэмдэглэгээнээс харагдахгүй. Peering-ийн холболт болон өөр хэн нэгний гарцыг ашиглах зөвшөөрөл нь тусдаа тохиргоо тул бие биеэ ping хийж чаддаг хоёр VM нь VPN замны талаар юу ч батлахгүй.
Эхний нөхцөл: гарц, мөн spoke-д түүний байхгүй байдал
Azure нь Basic-ээс бусад VPN Gateway SKU-д гарцын дамжуулалтыг дэмждэг бөгөөд бүс нутгийн болон дэлхийн peering хоёулаа үүнийг зөөж чадна. Spoke нь өөрийн мэдэлд байхгүй гарцыг ашигладаг тул өөрийн гэсэн гарцтай байж чадахгүй: хэрэв spoke-д аль хэдийн гарц байгаа эсвэл алсын гарцын сонголт аль хэдийн сонгогдсон бол таны хүссэн дамжуулалтын тохиргоо боломжгүй эсвэл үр дүнгүй байх болно. Ямар нэг зүйлийг дибаг хийхээс өмнө үүнийг шалгаарай, учир нь идэвхгүй болсон чекбокс нь шинж тэмдэг бөгөөд гэмтэл биш. Эхлээд SKU болон одоо байгаа гарцыг уншаад, дараа нь peering-ийн тохиргоог харна уу.
Сонголт гарч ирэхийн тулд одоо байгаа spoke гарцыг түүнээс юу хамааралтайг мэдэхээс өмнө бүү устга. Шилжилтийн дараалал чекбоксоос илүү чухал.
Хоёр дахь нөхцөл: peering-ийн чиглэл бүрт нэг тохиргоо
Peering нь хоёр объект, VNet бүр дээр нэг, дамжуулалтын тохиргоо нь тэр хосын өөр өөр талд байдаг. Hub-аас spoke руу чиглэсэн peering нь hub-ийн гарцыг spoke-д үйлчлэх боломж олгох ёстой; spoke-оос hub руу чиглэсэн peering нь hub-ийн гарцыг хүлээн авах ёстой. Microsoft-ийн гарцын дамжуулалтын гарын авлага тэдгээрийг чиглэлээр нэрлэдэг бөгөөд тэдгээрийг зөв байлгах цорын ганц арга зам нь энэ юм:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote гэсэн шошготой удирдлага нь аль VNet-ийн peering-ийг засаж буйгаас хамаарч утга өөрчлөгддөг тул үгийг биш, чиглэлийг уншаарай. Хоёр талыг тохируулж, хадгалаад, peering хоёр газарт холбогдсон гэж мэдээлж буйг баталгаажуулаарай.
Гурав дахь нөхцөл: хаягийн орон зай ба зөвшөөрлийн хил
Дамжуулалт нь ижил очих префиксыг хоёр сүлжээ гэж утгах боломжгүй тул hub, spoke болон дотоод сүлжээний хүрээ нь эдгээрийн аль нэг ажиллахаас өмнө давхцахгүй байх ёстой. VNet-үүд өөр өөр захиалга эсвэл өөр өөр түрээслэгчид байж болно; энэ нь хориг биш, гэхдээ peering бүрийг үүсгэж эсвэл шинэчилж буй таних тэмдэг нь тухайн сүлжээн дээр шаардлагатай зөвшөөрөлтэй байх ёстой. Захиалга хоорондын өөрчлөлтүүд ихэвчлэн зөвшөөрлийн улмаас бүтэлгүйтдэг бөгөөд алдааг топологийн асуудал гэж буруу уншихад амархан.
Өөрчлөлтийн өмнө хүрээ болон эзэмшигчдийг бичиж аваарай. Аль нэгийг нь таамаглах нь холбогддог боловч юу ч маршрутладаггүй peering үүсгэдэг.
Peering-ийн төлөвөөр биш, үр дүнтэй маршрутаар шалгаарай
Spoke ажлын ачааллын сүлжээний интерфейс дээрх үр дүнтэй маршрутуудыг харж, дотоод сүлжээний бодит префиксыг олоорой. Дэд сүлжээний маршрутын хүснэгт болон гарцын маршрутын тархалт идэвхгүй эсэхийг шалгаарай, учир нь хэрэглэгчийн тодорхойлсон маршрут эсвэл шалгалтын төхөөрөмж peering-ийн тугнууд санал болгож буй замыг дарж болно. Дараа нь эсрэг чиглэлийг баталгаажуулаарай: дотоод сүлжээ нь site-to-site холболтоор spoke-ийн префиксд хэрхэн хүрэхээ мэдэх ёстой, энэ нь сурсан зарлалуудаар эсвэл тодорхой маршрут болон хэрэглэгчийн төхөөрөмж дээрх тохирох хамгаалагдсан сүлжээний бичлэгээр байж болно. Хэрэв префикс аль нэг талд байхгүй бол өөрчлөх ёстой зүйл нь peering-ийн тугнууд биш.
Spoke ажлын ачааллаас нэг үйлчилгээг туршиж, хариуг дагаарай. VPN гарц эсвэл hub-ийн VM-ээс хийсэн туршилт нь өөр эх үүсвэрийн префикс, өөр зам ашигладаг.
Хэрэв топологи нь point-to-site клиентүүдэд ч үйлчилдэг бол тэдгээрийн суулгасан маршрутыг тусад нь баталгаажуулаарай. Топологи өөрчлөгдсөний дараа Windows клиентийн багцуудыг дахин үүсгэх шаардлагатай болж болно, бөгөөд энэ нь гарц хуваалцалт бүтэлгүйтсэн гэсэн баталгаа биш, клиентийн маршрутжуулалтын ажил юм.
Гарц хуваалцах нь юу өгөхгүй вэ
Гарцын дамжуулалт нь маршрутжуулалтын тав тух, зөвшөөрөл биш. Сүлжээний аюулгүй байдлын бүлгүүд, дотоод шүүлтүүр, үйлчилгээний түвшний дүрмүүд spoke ажлын ачаалал юунд хүрч болохыг шийдсээр байдаг тул хуваалцсан туннель түүний ард байгаа бүхнийг зөвшөөрдөг гэж үзэхийн оронд тодорхой эх үүсвэрээс очих газар хүртэлх үйлчилгээг идэвхжүүлээрэй.
Peering нь хүмүүсийн найдаж байгаа шиг дамжуулагч биш. Бас нэг spoke эсвэл хувийн төгсгөлийн цэг нэмэх нь одоо байгаа дамжуулалтын тохиргоонд хамаарахгүй өөрийн маршрутжуулалт болон нэвтрэх шаардлагуудыг авчирдаг.