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, които скриват адреси на източника, и всичко, което мониторингът е научил да очаква от неговия адрес. Запазете необходимите маршрути и тестван път за възстановяване, докато поддържаната цел се проектира и валидира редом.

Дръжте поддържаемостта и техническата диагностика като отделни констатации през цялото време. Неподдържано подреждане може да има и обикновена маршрутизационна грешка и коригирането ѝ не променя статуса му на поддръжка. И двете твърдения принадлежат в доклада и нито едно не отменя другото.

Затворете разходката, като запишете цитата за поддръжка, списъка с изисквания, избраната замяна и реда за преминаване. Тези четири елемента са първото, което одитор или нов член на екипа ще поиска.