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, що приховують адреси джерела, і всього, що моніторинг навчився очікувати від її адреси. Збережіть потрібні маршрути та перевірений шлях відновлення, поки підтримувана ціль проєктується й перевіряється поряд.

Тримайте підтримуваність і технічну діагностику як окремі висновки весь час. Непідтримуване впорядкування може мати й звичайну помилку маршрутизації, і виправлення цієї помилки не змінює його статус підтримки. Обидва твердження належать звіту, і жодне не скасовує інше.

Завершіть керівництво, записавши посилання на підтримку, список вимог, обрану заміну та порядок переходу. Ці чотири пункти — перше, що запитає аудитор або новий член команди.