RRAS на виртуальной машине Azure не поддерживается: проверьте до проектирования

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

Приведённое ниже руководство начинается со страницы поддержки, а затем переходит к требованиям и вариантам замены.

Начните со страницы поддержки, а не в лаборатории

Прочитайте рекомендации по поддержке виртуальных машин Azure, прежде чем что-либо рассчитывать. Они разделяют поддерживаемые продукты, роли и функции, вместо того чтобы рассматривать Windows Server как один неразделённый блок. Обратите внимание, в какую строку на самом деле попадает планируемая нагрузка, потому что два компонента, которые в консоли выглядят связанными, могут находиться в разных строках.

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

Отделите поддержку ОС от поддержки ролей и функций

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

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

Держите эти два вопроса раздельно до конца проекта: работает ли это и поддерживается ли это. Для каждого понадобятся разные ответы, а иногда и разные ответственные.

Запишите, что проект действительно должен делать

Прежде чем выбирать замену, превратите список площадок в требования, по которым можно измерять продукт:

• Протоколы туннелей, на которых уже говорят устройства филиалов, и нужна ли какой-либо площадке динамическая маршрутизация.
• Удалённые префиксы, включая любое перекрывающееся адресное пространство, которому нужна трансляция, а не маршрутизация.
• Обмен маршрутами с Azure и то, кто владеет каждой записью таблицы маршрутизации.
• Пропускная способность и число соединений, которые должен выдерживать самый загруженный час.
• Поведение при отказе, согласованное владельцами площадок, а не только то, которое вы можете построить.

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

Отнесите список владельцам сети и подтвердите его до любого обсуждения продуктов. Неоднозначные требования превращают любое сравнение поставщиков в спор о предпочтениях.

Оцените замены по этим требованиям

Управляемые службы подключения Azure и поддерживаемые поставщиками виртуальные сетевые устройства должны обе оцениваться по одному и тому же списку. Не считайте ни одно из них прямым эквивалентом виртуальной машины с RRAS только потому, что оно умеет завершать IPsec: модель NAT и владение маршрутами и проектирование высокой доступности определяют, как подключаются существующие площадки и куда возвращаются их ответы. Оцените каждого кандидата на бумаге по списку и запишите, какие требования он не выполняет, потому что именно эта заметка делает выбор проверяемым позже.

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

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

Если виртуальная машина с RRAS уже работает

Обнаружение не является причиной её удалять. Планируйте изменение вокруг зависимостей, которые эта машина накопила: маршрутов, на которые полагаются другие подсети, правил NAT, скрывающих адреса источника, и всего, что мониторинг научился ожидать от её адреса. Сохраните необходимые маршруты и проверенный путь восстановления, пока поддерживаемая цель проектируется и проверяется рядом.

Держите поддерживаемость и техническую диагностику как отдельные выводы на протяжении всего времени. Неподдерживаемая конфигурация может иметь и обычную ошибку маршрутизации, и исправление этой ошибки не меняет её статус поддержки. Оба утверждения относятся к отчёту, и ни одно не отменяет другое.

Завершите руководство, записав ссылку на поддержку, список требований, выбранную замену и порядок перехода. Эти четыре пункта — первое, что спросит аудитор или новый член команды.