RRAS op een Azure-VM wordt niet ondersteund: controleer vóór het ontwerp

U opent de portal, implementeert Windows Server 2022 in een subnet en de rol Remote Access wordt zonder problemen geïnstalleerd. Die volgorde bewijst dat het installatieprogramma werkt, niet dat Microsoft de configuratie ondersteunt. De gepubliceerde supportrichtlijnen voor serversoftware voor Azure-virtuele machines noemen RRAS onder de Windows Server-functies die niet worden ondersteund op Azure-VM's, en dat is een architectuurbeslissing, geen detail van probleemoplossing. Een tunnel die omhoog komt, verplaatst de implementatie niet binnen de supportgrens.

De onderstaande uiteenzetting begint op de supportpagina en werkt van daaruit naar eisen en vervangingsopties.

Begin op de supportpagina, niet in het lab

Lees de supportrichtlijnen voor Azure-VM's voordat u iets dimensioneren gaat. Ze scheiden ondersteunde producten, rollen en functies in plaats van Windows Server als één ongedifferentieerd blok te behandelen. Let op onder welke rij uw beoogde werkbelasting werkelijk valt, want twee componenten die in de console verwant lijken, kunnen in verschillende rijen staan.

Schrijf de verwijzing in het ontwerpdocument terwijl de pagina open is. Supportstatus is een feit met een bron, en een ontwerpbeoordeling die die niet kan citeren, wordt door degene met de demo onderuit gehaald.

Scheid OS-support van support voor rollen en functies

Dezelfde richtlijnen noemen Network Policy and Access Services onder de ondersteunde rollen, terwijl RRAS afzonderlijk als niet ondersteund wordt genoemd. Die twee vermeldingen beschrijven verschillende dingen, en ze samenvoegen tot „remote access wordt ondersteund“ is hoe een project op een verkeerde lezing wordt goedgekeurd. Dat het besturingssysteem wordt ondersteund, zegt niets over een functie met een eigen rij.

De beperking is ook smaller dan er soms wordt geciteerd. Ze betreft die functie die binnen een Azure-VM draait; ze betekent niet dat een particulier netwerk geen verbinding met Azure kan maken, en ze zegt niet dat RRAS nergens wordt ondersteund. Een ouder lab dat pakketten correct doorstuurt, is bewijs over pakketten, niet over de supportverklaring.

Houd die twee vragen voor de rest van het project gescheiden: werkt het, en wordt het ondersteund. U hebt voor elk verschillende antwoorden en soms verschillende eigenaren nodig.

Schrijf op wat het ontwerp werkelijk moet doen

Voordat u een vervanging kiest, maakt u van de sitelijst eisen waaraan een product kan worden gemeten:

• Tunnelprotocollen die de apparaten van de filialen al spreken, en of een site dynamische routering nodig heeft.
• Externe prefixen, inclusief elke overlappende adresruimte die vertaling in plaats van routering vereist.
• Routenuitwisseling met Azure, en wie elk item in de routetabel bezit.
• Doorvoer en aantallen verbindingen die het drukste uur moet volhouden.
• Failovergedrag waar de site-eigenaren mee hebben ingestemd, niet alleen wat u kunt bouwen.

NAT is het item dat wordt overgeslagen en vervolgens het hele ontwerp bepaalt. Een apparaat dat IPsec kan opzetten, kan adressen nog steeds anders vertalen dan de RRAS-implementatie die het vervangt, en dat verandert wat het filiaal als bronadressen ziet en wat uw logs vastleggen.

Neem de lijst mee naar de netwerkeigenaren en bevestig die vóór enige productdiscussie. Onduidelijke eisen maken elke leveranciersvergelijking tot een voorkeursdiscussie.

Beoordeel vervangingen tegen die eisen

De beheerde connectivitydiensten van Azure en door leveranciers ondersteunde virtuele netwerkapparaten moeten beide tegen dezelfde lijst worden gescoord. Ga er niet van uit dat een van beide een direct equivalent van een RRAS-VM is, alleen omdat het IPsec kan beëindigen: het NAT-model en het eigendom van routes en het ontwerp voor hoge beschikbaarheid bepalen hoe bestaande sites verbinden en waar hun antwoorden terugkomen. Scoor elke kandidaat op papier tegen de lijst en noteer welke eisen hij niet haalt, want die notitie maakt de keuze later herziebaar.

Een loadbalancer voor twee apparaat-VM's is op zichzelf geen hoge beschikbaarheid. Hij levert een front-end, geen gesynchroniseerde tunnelstatus, en een failover die elke sessie laat vallen is een ontwerpkeuze die iemand bewust moet maken. Vraag de apparaatleverancier welk HA-patroon wordt ondersteund en of dat overeenkomt met de beschikbaarheid die de sites is beloofd. Test de failover voordat die sites ervan afhankelijk zijn, en behandel elke verloren sessie als een bevinding en niet als een verrassing.

Waar de eis echt eenvoudig is — één site, één prefix, geen overlap — wint een beheerde dienst meestal op operationele kosten. Waar vertaling en dynamische routering beide in het spel zijn, kan de apparaatroute de enige passende zijn, en dat is een reden om een langere migratie te plannen in plaats van de niet-ondersteunde VM te houden.

Als er al een RRAS-VM draait

Ontdekking is geen reden om hem te verwijderen. Plan de wijziging rond de afhankelijkheden die die VM heeft opgebouwd: routes waarop andere subnetten vertrouwen, NAT-regels die bronadressen verbergen, en alles wat monitoring heeft geleerd van zijn adres te verwachten. Behoud de vereiste routes en een getest herstelpad terwijl het ondersteunde doel ernaast wordt ontworpen en gevalideerd.

Houd ondersteunbaarheid en technische diagnose doorlopend als afzonderlijke bevindingen. Een niet-ondersteunde opstelling kan ook een gewone routeringsfout hebben, en het verhelpen van die fout verandert de supportstatus niet. Beide uitspraken horen in het rapport, en geen van beide heft de andere op.

Sluit de uiteenzetting af door de supportverwijzing, de eisenlijst, de gekozen vervanging en de volgorde van omschakeling vast te leggen. Die vier punten zijn wat een auditor of een nieuw teamlid als eerste zal vragen.