Azure VM дээр RRAS дэмжигдэхгүй: дизайны өмнө шалгаарай

Та порталыг нээж, Windows Server 2022-ыг дэд сүлжээнд байрлуулж, Remote Access үүрэг ямар ч асуудалгүй суудаг. Энэ дараалал суулгагч ажиллаж байгааг нотолж байгаа бөгөөд Microsoft энэ тохиргоог дэмждэг гэсэн үг биш. Azure виртуал машинуудад зориулсан нийтлэгдсэн серверийн програм хангамжийн дэмжлэгийн заавар RRAS-ыг Azure VM дээр дэмжигдэхгүй Windows Server боломжуудын тоонд оруулдаг бөгөөд энэ нь архитектурын шийдвэр, алдаа засахын деталь биш. Босдог туннель байршуулалтыг дэмжлэгийн хязгаар дотор зөөдөггүй.

Доорх гарын авлага дэмжлэгийн хуудаснаас эхэлж, дараа нь шаардлага, орлуулах хувилбарууд руу шилждэг.

Лабораториос биш, дэмжлэгийн хуудаснаас эхэл

Ямар нэг зүйлийг хэмжихээс өмнө Azure VM-ийн дэмжлэгийн зааврыг уншаарай. Энэ нь Windows Server-ыг нэг ялгаагүй блок гэж үзэхийн оронд дэмжигддэг бүтээгдэхүүн, үүрэг, боломжуудыг тусгаарладаг. Таны төлөвлөж буй ажлын ачаалал үнэхээр аль мөрөнд хамаарахыг анхаараарай, учир нь консол дээр холбоотой харагдах хоёр бүрэлдэхүүн өөр өөр мөрөнд байж болно.

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

Үйлдлийн системийн дэмжлэгийг үүрэг, боломжийн дэмжлэгээс тусгаарла

Мөн заавар Network Policy and Access Services-ийг дэмжигддэг үүргүүдийн дунд жагсаасан бол RRAS-ыг тусад нь дэмжигдэхгүй гэж жагсаасан. Эдгээр хоёр бичлэг өөр өөр зүйлийг тодорхойлдог бөгөөд тэдгээрийг «алсын хандалт дэмжигддэг» гэж нэгтгэх нь төслийг буруу уншсан үндэслэлээр батлах зам. Үйлдлийн систем дэмжигдэх нь өөрийн мөртэй боломжийн талаар юу ч хэлдэггүй.

Хязгаарлалт нь заримдаа иш татдагтай харьцуулахад ч илүү нарийн. Энэ нь Azure VM дотор ажиллаж буй тэр боломжид хамаарна; энэ нь хувийн сүлжээ Azure-тай холбогдож чадахгүй гэсэн үг биш бөгөөд RRAS хаа сайгүй дэмжигдэхгүй гэж ч хэлэхгүй. Пакетыг зөв дамжуулдаг хуучин лаборатори пакетын тухай нотолгоо бөгөөд дэмжлэгийн мэдэгдлийн тухай биш.

Төслийн үлдсэн хугацаанд эдгээр хоёр асуултыг тусад нь бариарай: ажиллаж байна уу, дэмжигдэж байна уу. Асуулт бүрт өөр хариулт, заримдаа өөр хариуцагч хэрэгтэй болно.

Дизайн үнэхээр юу хийх ёстойгоо бич

Орлуулагчийг сонгохын өмнө сайтуудын жагсаалтыг бүтээгдэхүүнийг хэмжиж болох шаардлага болгон хувиргаарай:

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

NAT бол алгасагддаг, дараа нь бүх дизайныг шийддэг зүйл юм. IPsec тогтоож чадах төхөөрөмж орлуулж буй RRAS байршуулалтаас өөрөөр хаягийг орчуулж болох бөгөөд энэ нь салбар ямар хаягийг эх сурвалж гэж харах, таны лог юу бүртгэхийг өөрчилдөг.

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

Орлуулагчдыг тэдгээр шаардлагад харьцуулан үнэл

Azure-ын удирдлагатай холболтын үйлчилгээнүүд болон нийлүүлэгчдийн дэмждэг сүлжээний виртуал төхөөрөмжүүд хоёулаа нэг жагсаалтад харьцуулан үнэлэгдэх ёстой. IPsec-ийг дуусгаж чаддаг гэсэн шалтгаанаар аль нэгийг нь RRAS VM-ийн шууд эквивалент гэж бүү үзээрэй: NAT загвар, маршрутын эзэмшил болон өндөр боломжийн дизайн нь одоо байгаа сайтууд хэрхэн холбогдож, тэдний хариулт хаашаа буцахыг шийддэг. Өрсөлдөгч бүрийг цаасан дээр жагсаалтад харьцуулан үнэлж, ямар шаардлагыг хангахгүй байгааг бичээрэй, учир нь тэр тэмдэглэл сонголтыг дараа нь хянах боломжтой болгодог.

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

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

RRAS VM аль хэдийн ажиллаж байгаа бол

Илрүүлэлт нь түүнийг устгах шалтгаан биш. Өөрчлөлтийг тэр VM хуримтлуулсан хамаарлуудын эргэн тойронд төлөвлө: бусад дэд сүлжээнүүд найдаж буй маршрутууд, эх хаягийг нуудаг NAT дүрмүүд, мониторинг түүний хаягаас хүлээж сурсан бүх зүйл. Дэмжигддэг зорилтыг хажууд нь зохиож, баталгаажуулах хооронд шаардлагатай маршрутууд болон туршсан сэргээх замыг хадгал.

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

Гарын авлагыг дэмжлэгийн ишлэл, шаардлагын жагсаалт, сонгосон орлуулагч, шилжилтийн дарааллыг бичиж дуусга. Аудитор эсвэл шинэ багийн гишүүн хамгийн түрүүнд эдгээр дөрвөн зүйлийг асууна.