RRAS на Azure VM не падтрымліваецца: праверце да праектавання

Вы адкрываеце партал, разгортваеце Windows Server 2022 у падсетку, і роля Remote Access усталёўваецца без памылак. Гэтая паслядоўнасць даказвае, што ўсталёўшчык працуе, а не што Microsoft падтрымлівае такую канфігурацыю. Апублікаваныя рэкамендацыі па падтрымцы сервернага праграмнага забеспячэння для віртуальных машын Azure уключаюць RRAS у лік функцый Windows Server, якія не падтрымліваюцца на Azure VM, і гэта рашэнне аб архітэктуры, а не дэталь пошуку няспраўнасцей. Тунель, які ўзнімаецца, не пераносіць разгортванне ўнутры мяжы падтрымкі.

Праходка ніжэй пачынаецца са старонкі падтрымкі, а затым пашыраецца да патрабаванняў і варыянтаў замены.

Пачніце са старонкі падтрымкі, а не ў лабараторыі

Прачытайце рэкамендацыі па падтрымцы Azure VM, перш чым вызначаць памеры. Яны падзяляюць прадукты, ролі і функцыі, якія падтрымліваюцца, замест таго каб разглядаць Windows Server як адзін непадзельны блок. Звярніце ўвагу, у які радок трапляе ваша планаваная нагрузка, бо два кампаненты, якія ў кансолі выглядаюць звязанымі, могуць знаходзіцца ў розных радках.

Запішыце цытату ў дакумент праектавання, пакуль старонка адкрыта. Статус падтрымкі — гэта факт з крыніцай, і праектнае рэвю, якое не можа на яго спасылацца, прайграе таму, у каго ёсць дэма.

Аддзяліце падтрымку АС ад падтрымкі роляў і функцый

Тыя ж рэкамендацыі ўключаюць Network Policy and Access Services у лік падтрымліваных роляў, а RRAS асобна падаюць як непадтрымліваную. Гэтыя два запісы апісваюць рознае, і зліццё іх у «аддалены доступ падтрымліваецца» — гэта шлях да зацвярджэння праекта на падставе памылковага чытання. Падтрымка аперацыйнай сістэмы нічога не кажа пра функцыю, якая мае свой радок.

Абмежаванне таксама вузейшае, чым яго часам цытуюць. Яно датычыцца гэтай функцыі, якая працуе ўнутры Azure VM; яно не азначае, што прыватная сетка не можа злучыцца з Azure, і не сцвярджае, што RRAS не падтрымліваецца нідзе. Старая лабараторыя, якая правільна перасылае пакеты, — гэта доказ пра пакеты, а не пра заяву аб падтрымцы.

Трымайце гэтыя два пытанні асобна да канца праекта: ці працуе яно і ці падтрымліваецца. Вам спатрэбяцца розныя адказы, а часам і розныя адказныя асобы для кожнага.

Запішыце, што праект фактычна павінен рабіць

Перш чым выбіраць замену, пераўтварыце спіс пляцовак у патрабаванні, па якіх можна ацэньваць прадукт:

• Пратаколы тунеляў, якія ўжо выкарыстоўваюць прылады філіялаў, і ці патрэбна нейкай пляцоўцы дынамічная маршрутызацыя.
• Аддаленыя прэфіксы, уключаючы любую адрасную прастору, якая перакрываецца і патрабуе трансляцыі, а не маршрутызацыі.
• Абмен маршрутамі з Azure і тое, хто валодае кожным запісам табліцы маршрутаў.
• Прапускная здольнасць і колькасць злучэнняў, якія павінна вытрымаць самая загружаная гадзіна.
• Паводзіны пры адмове, на якія пагадзіліся ўладальнікі пляцовак, а не толькі тыя, якія вы можаце пабудаваць.

NAT — гэта пункт, які прапускаюць, а потым ён вызначае ўвесь праект. Прылада, якая можа ўстанавіць IPsec, можа трансляваць адрасы інакш, чым разгортванне RRAS, якое яна замяняе, і гэта змяняе тое, што філіял бачыць як адрасы крыніцы і што запісваюць вашыя журналы.

Вазьміце спіс да ўладальнікаў сеткі і пацвердзіце яго перад любым абмеркаваннем прадуктаў. Неадназначныя патрабаванні ператвараюць любое параўнанне пастаўшчыкоў у спрэчку пра густы.

Ацаніце замены адносна гэтых патрабаванняў

Кіраваныя службы падключэння Azure і сеткавыя віртуальныя прылады, якія падтрымліваюцца пастаўшчыкамі, трэба ацэньваць па адным і тым жа спісе. Не лічыце ніводную з іх прамым эквівалентам RRAS VM толькі таму, што яна можа завяршаць IPsec: мадэль NAT і ўладанне маршрутамі і праектаванне высокай даступнасці вызначаюць, як злучаюцца існуючыя пляцоўкі і куды вяртаюцца іх адказы. Ацаніце кожнага кандыдата на паперы па спісе і запішыце, якія патрабаванні ён не выконвае, бо менавіта гэтая заўвага робіць выбар прыдатным для разгляду пазней.

Балансіроўшчык нагрузкі перад двума VM-прыладамі сам па сабе не ёсць высокай даступнасцю. Ён дае франтальную частку, а не сінхранізаваны стан тунеляў, і адмова, якая скідвае кожную сесію, — гэта праектнае рашэнне, якое хтосьці павінен прыняць свядома. Спытайце ў пастаўшчыка прылады, які падтрымліваны шаблон HA і ці адпавядае ён даступнасці, абяцанай пляцоўкам. Праверце адмову да таго, як гэтыя пляцоўкі стануць ад яе залежаць, і разглядайце кожную страчаную сесію як знаходку, а не як нечаканасць.

Там, дзе патрабаванне сапраўды простае — адна пляцоўка, адзін прэфікс, без перакрыцця — кіраваная служба звычайна перамагае па эксплуатацыйных выдатках. Там, дзе адначасова ўдзельнічаюць трансляцыя і дынамічная маршрутызацыя, шлях праз прыладу можа быць адзіным прыдатным, і гэта прычына планаваць даўжэйшую міграцыю, а не трымаць непадтрымліваемую VM.

Калі RRAS VM ужо працуе

Выяўленне не з'яўляецца прычынай выдаляць яе. Плануйце змену вакол залежнасцей, якія назапасіла гэтая VM: маршрутаў, на якія спадзяюцца іншыя падсеткі, правіл NAT, якія хаваюць адрасы крыніцы, і ўсяго таго, што маніторынг навучыўся чакаць ад яе адраса. Захавайце патрэбныя маршруты і правераны шлях аднаўлення, пакуль падтрымліваная мэта праектуецца і правяраецца побач.

Трымайце падтрымліванасць і тэхнічную дыягностыку асобнымі высновамі на працягу ўсяго часу. Непадтрымліваемая схема можа таксама мець звычайную памылку маршрутызацыі, і выпраўленне гэтай памылкі не змяняе яе статус падтрымкі. Абедзве заявы належаць справаздачы, і ні адна не адмяняе другую.

Завяршыце праходку, запісаўшы цытату аб падтрымцы, спіс патрабаванняў, выбраную замену і парадак пераключэння. Гэтыя чатыры пункты — першае, што спытае аўдытар або новы член каманды.