RRAS op 'n Azure-VM word nie ondersteun nie: kyk voor jy ontwerp

Jy open die portaal, ontplooi Windows Server 2022 in 'n subnet, en die Remote Access-rol installeer sonder probleme. Daardie volgorde bewys dat die installeerder werk, nie dat Microsoft die opset ondersteun nie. Die gepubliseerde ondersteuningsleiding vir bedienerprogrammatuur vir Azure virtuele masjiene lys RRAS onder die Windows Server-funksies wat nie op Azure-VM's ondersteun word nie, en dit is 'n argitektuurbesluit eerder as 'n foutopsporingsdetail. 'n Tonnel wat opkom, skuif nie die ontplooiing binne die ondersteuningsgrens nie.

Die deurloop hieronder begin op die ondersteuningsblad en werk dan uitwaarts na vereistes en vervangingsopsies.

Begin op die ondersteuningsblad, nie in die laboratorium nie

Lees die Azure VM-ondersteuningsleiding voordat jy enigiets beplan. Dit skei ondersteunde produkte, rolle en funksies in plaas daarvan om Windows Server as een ongedifferensieerde blok te behandel. Let op onder watter ry jou beoogde werklading eintlik val, want twee komponente wat in die konsole verwant lyk, kan in verskillende rye sit.

Skryf die aanhaling in die ontwerpdocument terwyl die bladsy oop is. Ondersteuningstatus is 'n feit met 'n bron, en 'n ontwerphersiening wat dit nie kan aanhaal nie, sal deur die een met die demo weggeredeneer word.

Skei bedryfstelselondersteuning van rol- en funksieondersteuning

Dieselfde leiding lys Network Policy and Access Services onder ondersteunde rolle, terwyl RRAS afsonderlik as onondersteun gelys word. Daardie twee inskrywings beskryf verskillende dinge, en om hulle saam te voeg as “remote access word ondersteun” is hoe 'n projek op 'n verkeerde lesing goedgekeur word. Dat die bedryfstelsel ondersteun word, sê niks oor 'n funksie met sy eie ry nie.

Die beperking is ook smaller as wat dit soms aangehaal word. Dit handel oor daardie funksie wat binne 'n Azure-VM loop; dit beteken nie dat 'n privaatnetwerk nie aan Azure kan koppel nie, en dit sê nie RRAS word oral onondersteun nie. 'n Ouer laboratorium wat pakkette korrek aanstuur, is bewyse oor pakkette, nie oor die ondersteuningsverklaring nie.

Hou daardie twee vrae vir die res van die projek apart: werk dit, en word dit ondersteun. Jy sal verskillende antwoorde en soms verskillende eienaars vir elkeen nodig hê.

Skryf neer wat die ontwerp werklik moet doen

Voordat jy 'n vervanging kies, verander die werfelys in vereistes waaraan 'n produk gemeet kan word:

• Tonnelprotokolle wat die taktoestelle reeds praat, en of enige werf dinamiese roetering nodig het.
• Afgeleë prefikse, insluitend enige oorvleuelende adresruimte wat vertaling eerder as roetering nodig het.
• Roete-uitruiling met Azure, en wie elke roetetabelinskrywing besit.
• Deurset en verbindingstellings wat die besigste uur moet volhou.
• Oorskuifgedrag waartoe die werfeienaars ingestem het, nie net dié wat jy kan bou nie.

NAT is die item wat oorgeslaan word en dan die hele ontwerp besluit. 'n Toestel wat IPsec kan vestig, kan adresse steeds anders vertaal as die RRAS-ontplooiing wat dit vervang, wat verander wat die tak as bronadresse sien en wat jou logboeke aanteken.

Neem die lys na die netwerkeienaars en bevestig dit voor enige produkbespreking. Dubbelsinnige vereistes verander elke verskaffervergelyking in 'n voorkeurargument.

Evalueer vervangings teen daardie vereistes

Azure se bestuurde konnektiwiteitsdienste en verskafferondersteunde netwerk virtuele toestelle moet albei teen dieselfde lys beoordeel word. Moenie aanvaar dat enigeen 'n direkte ekwivalent van 'n RRAS-VM is net omdat dit IPsec kan termineer nie: die NAT-model en roete-eienaarskap en hoëbeskikbaarheidsontwerp bepaal hoe bestaande werwe koppel en waar hul antwoorde terugkeer. Punt elke kandidaat op papier teen die lys en skryf neer watter vereistes dit nie haal nie, want daardie nota maak die keuse later hersienbaar.

'n Lasbalanseerder voor twee toestel-VM's is nie op sigself hoë beskikbaarheid nie. Dit voorsien 'n front-end, nie gesinkroniseerde tonneltoestand nie, en 'n oorskuif wat elke sessie laat val, is 'n ontwerpkeuse wat iemand doelbewus moet maak. Vra die toestelverskaffer wat die ondersteunde HA-patroon is en of dit ooreenstem met die beskikbaarheid wat aan die werwe belowe is. Toets die oorskuif voordat daardie werwe daarvan afhanklik is, en behandel elke verlore sessie as 'n bevinding eerder as 'n verrassing.

Waar die vereiste werklik eenvoudig is — een werf, een prefiks, geen oorvleueling — wen 'n bestuurde diens gewoonlik op bedryfskoste. Waar vertaling en dinamiese roetering albei in die spel is, mag die toestelpad die enigste pas wees, en dit is 'n rede om 'n langer migrasie te beplan eerder as om die onondersteunde VM te hou.

As 'n RRAS-VM reeds loop

Ontdekking is nie 'n rede om dit te verwyder nie. Beplan die verandering rondom die afhanklikhede wat daardie VM opgebou het: roetes waarop ander subnette staatmaak, NAT-reëls wat bronadresse verberg, en alles wat monitering geleer het om van sy adres te verwag. Bewaar die vereiste roetes en 'n getoetste herstelpad terwyl die ondersteunde teiken daarlangs ontwerp en gevalideer word.

Hou ondersteunbaarheid en tegniese diagnose regdeur as afsonderlike bevindings. 'n Onondersteunde reëling kan ook 'n gewone roeteringsfout hê, en om daardie fout reg te maak verander nie sy ondersteuningstatus nie. Albei stellings hoort in die verslag, en nie een kanselleer die ander nie.

Sluit die deurloop af deur die ondersteuningsaanhaling, die vereistelys, die gekose vervanging en die oorskakelorde vas te lê. Daardie vier items is waarvoor 'n ouditeur of 'n nuwe spanlid eerste sal vra.