RRAS en una VM d'Azure no és compatible: comproveu-ho abans del disseny

Obriu el portal, desplegueu Windows Server 2022 en una subxarxa i el rol Remote Access s'instal·la sense problemes. Aquesta seqüència demostra que l'instal·lador funciona, no que Microsoft doni suport a aquesta configuració. Les directrius publicades de suport de programari de servidor per a màquines virtuals d'Azure inclouen RRAS entre les funcions de Windows Server que no tenen suport a les VM d'Azure, i això és una decisió d'arquitectura, no un detall de resolució d'incidències. Un túnel que s'aixeca no mou el desplegament dins de la frontera de suport.

El recorregut següent comença a la pàgina de suport i després s'estén cap als requisits i les opcions de substitució.

Comença a la pàgina de suport, no al laboratori

Llegiu les directrius de suport de les VM d'Azure abans de dimensionar res. Separen productes, rols i funcions compatibles en lloc de tractar Windows Server com un bloc indiferenciat. Fixeu-vos en quina fila cau realment la càrrega de treball prevista, perquè dos components que a la consola semblen relacionats poden seure en files diferents.

Escriviu la citació al document de disseny mentre la pàgina és oberta. L'estat de suport és un fet amb una font, i una revisió de disseny que no el pugui citar serà desmuntada per qui tingui la demo.

Separeu el suport del sistema operatiu del suport de rols i funcions

Les mateixes directrius inclouen Network Policy and Access Services entre els rols compatibles mentre enumeren RRAS per separat com a no compatible. Aquestes dues entrades descriuen coses diferents, i fusionar-les en «l'accés remot és compatible» és com s'aprova un projecte basat en una lectura errònia. Que el sistema operatiu sigui compatible no diu res sobre una funció que té la seva pròpia fila.

La limitació també és més estreta del que de vegades es cita. Fa referència a aquesta funció executant-se dins d'una VM d'Azure; no vol dir que una xarxa privada no pugui connectar-se a Azure, ni diu que RRAS no sigui compatible enlloc. Un laboratori antic que reenvia paquets correctament és una prova sobre paquets, no sobre la declaració de suport.

Manteniu aquestes dues preguntes separades durant la resta del projecte: funciona i és compatible. Necessitareu respostes diferents i de vegades propietaris diferents per a cadascuna.

Escriviu què ha de fer realment el disseny

Abans de triar una substitució, convertiu la llista de seus en requisits amb els quals es pugui mesurar un producte:

• Els protocols de túnel que ja parlen els dispositius de les sucursals, i si alguna seu necessita encaminament dinàmic.
• Els prefixos remots, incloent-hi qualsevol espai d'adreces solapat que necessiti traducció i no encaminament.
• L'intercanvi de rutes amb Azure, i qui posseeix cada entrada de la taula d'encaminament.
• El cabal i el nombre de connexions que l'hora més carregada ha de suportar.
• El comportament de failover que han acordat els propietaris de les seus, no només el que pugueu construir.

NAT és l'element que se salta i després decideix tot el disseny. Un dispositiu que pot establir IPsec encara pot traduir adreces de manera diferent del desplegament RRAS que substitueix, cosa que canvia què veu la sucursal com a adreces d'origen i què registren els vostres registres.

Porteu la llista als propietaris de la xarxa i confirmeu-la abans de qualsevol discussió sobre productes. Els requisits ambigus converteixen qualsevol comparació de proveïdors en una discussió de preferències.

Avalueu les substitucions contra aquests requisits

Els serveis de connectivitat gestionats d'Azure i les aplicacions virtuals de xarxa compatibles amb proveïdors s'han de puntuar contra la mateixa llista. No suposeu que cap dels dos és equivalent directe d'una VM RRAS només perquè pot acabar IPsec: el model NAT i la propietat de les rutes i el disseny d'alta disponibilitat decideixen com es connecten les seus existents i on tornen les seves respostes. Puntueu cada candidat sobre paper contra la llista i anoteu quins requisits incompleix, perquè aquesta nota és el que fa revisable l'elecció més endavant.

Un balancejador de càrrega davant de dues VM d'aplicació no és alta disponibilitat per si sol. Proporciona un front-end, no un estat de túnel sincronitzat, i un failover que deixa caure totes les sessions és una decisió de disseny que algú ha de prendre expressament. Pregunteu al proveïdor de l'aplicació quin és el patró HA compatible i si coincideix amb la disponibilitat promesa a les seus. Proveu el failover abans que aquestes seus en depenguin, i tracteu cada sessió perduda com una troballa i no com una sorpresa.

Quan el requisit és realment simple — una seu, un prefix, cap solapament — un servei gestionat sol guanyar en cost operatiu. Quan la traducció i l'encaminament dinàmic estan tots dos en joc, el camí de l'aplicació pot ser l'únic adequat, i això és una raó per planificar una migració més llarga en lloc de mantenir la VM no compatible.

Si ja hi ha una VM RRAS en funcionament

El descobriment no és una raó per esborrar-la. Planifiqueu el canvi al voltant de les dependències que aquesta VM ha acumulat: rutes de les quals depenen altres subxarxes, regles NAT que amaguen adreces d'origen i tot el que el monitoratge ha après a esperar de la seva adreça. Preserveu les rutes necessàries i un camí de recuperació provat mentre el destí compatible es dissenya i valida al costat.

Manteniu la suportabilitat i el diagnòstic tècnic com a troballes separades al llarg de tot. Una disposició no compatible també pot tenir un error d'encaminament corrent, i corregir aquest error no canvia el seu estat de suport. Les dues afirmacions pertanyen a l'informe i cap de les dues anul·la l'altra.

Tanqueu el recorregut registrant la citació de suport, la llista de requisits, la substitució triada i l'ordre de tall. Aquests quatre elements són el primer que demanarà un auditor o un membre nou de l'equip.