RRAS på en Azure VM støttes ikke: sjekk før design

Du åpner portalen, distribuerer Windows Server 2022 i et subnett, og Remote Access-rollen installeres rent. Den sekvensen beviser at installasjonsprogrammet virker, ikke at Microsoft støtter konfigurasjonen. Den publiserte støtteveiledningen for serverprogramvare for Azure-virtuelle maskiner lister RRAS blant Windows Server-funksjonene som ikke støttes på Azure VM-er, og det er en arkitekturbeslutning, ikke en feilsøkingsdetalj. En tunnel som kommer opp flytter ikke distribusjonen innenfor støttegrensen.

Gjennomgangen nedenfor starter på støttesiden og arbeider deretter utover mot krav og erstatningsalternativer.

Start på støttesiden, ikke i laboratoriet

Les støtteveiledningen for Azure VM-er før du dimensjonerer noe. Den skiller støttede produkter, roller og funksjoner i stedet for å behandle Windows Server som én udifferensiert blokk. Legg merke til hvilken rad den planlagte arbeidsbelastningen faktisk hører under, fordi to komponenter som ser beslektede ut i konsollen kan stå i forskjellige rader.

Skriv sitatet inn i designdokumentet mens siden er åpen. Støttestatus er et faktum med en kilde, og en designgjennomgang som ikke kan sitere den, vil bli snakket ned av den som har demoen.

Skill OS-støtte fra støtte for roller og funksjoner

Den samme veiledningen lister Network Policy and Access Services blant støttede roller, mens RRAS listes separat som ikke støttet. De to oppføringene beskriver forskjellige ting, og å slå dem sammen til «fjern tilgang støttes» er måten et prosjekt blir godkjent på en feillesning. At operativsystemet støttes, sier ingenting om en funksjon som har sin egen rad.

Begrensningen er også snevrere enn den noen ganger siteres. Den gjelder den funksjonen som kjører inne i en Azure VM; den betyr ikke at et privat nettverk ikke kan koble til Azure, og den sier ikke at RRAS ikke støttes overalt. Et eldre laboratorium som videresender pakker riktig, er bevis om pakker, ikke om støtteerklæringen.

Hold de to spørsmålene adskilt resten av prosjektet: virker det, og støttes det. Du trenger forskjellige svar og noen ganger forskjellige eiere for hvert av dem.

Skriv ned hva designet faktisk må gjøre

Før du velger en erstatning, gjør sitelisten om til krav et produkt kan måles mot:

• Tunnelprotokollene grenenes enheter allerede snakker, og om noen site trenger dynamisk ruting.
• Fjerntliggende prefikser, inkludert ethvert overlappende adresserom som trenger oversettelse i stedet for ruting.
• Ruteutveksling med Azure, og hvem som eier hver oppføring i rutetabellen.
• Gjennomstrømning og antall tilkoblinger den travleste timen må tåle.
• Failover-atferd som siteeierne har godtatt, ikke bare den du kan bygge.

NAT er elementet som hoppes over og deretter avgjør hele designet. En enhet som kan etablere IPsec, kan fortsatt oversette adresser annerledes enn RRAS-distribusjonen den erstatter, og det endrer hva grenen ser som kildeadresser og hva loggene dine registrerer.

Ta listen med til netteierne og bekreft den før noen produktdiskusjon. Tvetydige krav gjør enhver leverandørsammenligning til en preferansedebatt.

Vurder erstatninger mot disse kravene

Azures administrerte tilkoblingstjenester og leverandørstøttede virtuelle nettverksenheter må begge scores mot den samme listen. Ikke anta at noen av dem er en direkte ekvivalent til en RRAS VM bare fordi den kan avslutte IPsec: NAT-modellen og eierskapet til ruter og designet for høy tilgjengelighet avgjør hvordan eksisterende sites kobler til og hvor svarene deres kommer tilbake. Score hver kandidat på papir mot listen og skriv ned hvilke krav den ikke oppfyller, fordi den noten er det som gjør valget gjennomgåelig senere.

En lastbalanserer foran to appliance-VM-er er ikke høy tilgjengelighet i seg selv. Den leverer en front end, ikke synkronisert tunnelstatus, og et failover som dropper hver sesjon, er et designvalg noen må ta med vilje. Spør appliance-leverandøren hvilket støttet HA-mønster som gjelder, og om det samsvarer med tilgjengeligheten sitene ble lovet. Test failover før de sitene er avhengige av det, og behandle hver tapt sesjon som et funn og ikke en overraskelse.

Der kravet er virkelig enkelt — én site, ett prefiks, ingen overlapping — vinner en administrert tjeneste vanligvis på driftskostnader. Der oversettelse og dynamisk ruting begge er i spill, kan appliance-veien være den eneste passende, og det er grunnen til å planlegge en lengre migrering i stedet for å beholde den ustøttede VM-en.

Hvis en RRAS VM allerede kjører

Oppdagelse er ikke en grunn til å slette den. Planlegg endringen rundt avhengighetene den VM-en har samlet: ruter andre subnett er avhengige av, NAT-regler som skjuler kildeadresser, og alt overvåkingen har lært å forvente av adressen dens. Bevar de nødvendige rutene og en testet gjenopprettingsvei mens det støttede målet designes og valideres ved siden av.

Hold støttbarhet og teknisk diagnose som separate funn hele veien. En ustøttet ordning kan også ha en vanlig rutingfeil, og å rette den feilen endrer ikke støttestatusen. Begge utsagnene hører hjemme i rapporten, og ingen av dem opphever den andre.

Avslutt gjennomgangen med å registrere støttesitatet, kravlisten, den valgte erstatningen og rekkefølgen for overgangen. De fire punktene er det en revisor eller et nytt teammedlem først vil spørre om.