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

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

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