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 правила која скривају изворне адресе и свега што је мониторинг научио да очекује од његове адресе. Сачувајте потребне руте и тестирани пут опоравка док се подржани циљ пројектује и валидира упоредо.

Држите подрживост и техничку дијагностику као одвојене налазе све време. Неподржан распоред може имати и обичну грешку рутирања, а исправљање те грешке не мења његов статус подршке. Обе тврдње припадају извештају и ниједна не поништава другу.

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