RRAS på ein Azure VM er ikkje støtta: sjekk før design

Du opnar portalen, distribuerer Windows Server 2022 i eit subnett, og Remote Access-rolla blir installert reint. Den sekvensen provar at installasjonsprogrammet verkar, ikkje at Microsoft støttar konfigurasjonen. Den publiserte støttevegleiinga for serverprogramvare for Azure-virtuelle maskinar listar RRAS blant Windows Server-funksjonane som ikkje er støtta på Azure VM-ar, og det er eit arkitekturval, ikkje ein feilsøkingsdetalj. Ein tunnel som kjem opp flyttar ikkje distribusjonen innanfor støttegrensa.

Gjennomgangen nedanfor startar på støttesida og arbeider deretter utover mot krav og erstatningsalternativ.

Start på støttesida, ikkje i laboratoriet

Les støttevegleiinga for Azure VM-ar før du dimensjonerer noko. Ho skil støtta produkt, rollar og funksjonar i staden for å handsame Windows Server som éin udifferensiert blokk. Legg merke til kva rad den planlagde arbeidsbelastninga faktisk høyrer under, fordi to komponentar som ser skylde ut i konsollen kan stå i ulike rader.

Skriv sitatet inn i designdokumentet medan sida er open. Støttestatus er eit faktum med ei kjelde, og ein designgjennomgang som ikkje kan sitere henne, vil bli snakka ned av den som har demoen.

Skil OS-støtte frå støtte for rollar og funksjonar

Den same vegleiinga listar Network Policy and Access Services blant støtta rollar, medan RRAS blir lista separat som ikkje støtta. Dei to oppføringane skildrar ulike ting, og å slå dei saman til «fjern tilgang er støtta» er måten eit prosjekt blir godkjent på ei feillesing. At operativsystemet er støtta, seier ingenting om ein funksjon som har si eiga rad.

Avgrensinga er også snevrare enn ho nokre gonger blir sitert. Ho gjeld den funksjonen som køyrer inne i ein Azure VM; ho betyr ikkje at eit privat nettverk ikkje kan kople til Azure, og ho seier ikkje at RRAS ikkje er støtta overalt. Eit eldre laboratorium som vidaresender pakkar rett, er bevis om pakkar, ikkje om støttefråsegna.

Hald dei to spørsmåla fråskilde resten av prosjektet: verkar det, og er det støtta. Du treng ulike svar og nokre gonger ulike eigarar for kvart av dei.

Skriv ned kva designet faktisk må gjere

Før du vel ei erstatning, gjer sitelista om til krav eit produkt kan målast mot:

• Tunnelprotokollane greinene sine einingar allereie snakkar, og om nokon stad treng dynamisk ruting.
• Fjerntliggjande prefiks, inkludert eit kvart overlappande adresserom som treng omsetjing i staden for ruting.
• Ruteutveksling med Azure, og kven som eig kvar oppføring i rutetabellen.
• Gjennomstrøyming og talet på tilkoplingar den travlaste timen må tole.
• Failover-åtferd som siteeigarane har godteke, ikkje berre den du kan byggje.

NAT er elementet som blir hoppa over og deretter avgjer heile designet. Ei eining som kan opprette IPsec, kan framleis omsetje adresser annleis enn RRAS-distribusjonen ho erstattar, og det endrar kva greina ser som kjeldeadresser og kva loggane dine registrerer.

Ta lista med til netteigarane og stadfest henne før nokon produktdiskusjon. Tydvingslause krav gjer kvar leverandørsamanlikning til ein preferansedebatt.

Vurder erstatningar mot desse krava

Dei styrte tilkoplingstenestene til Azure og leverandørstøtta virtuelle nettverkseiningar må begge scorast mot den same lista. Ikkje gå ut frå at nokon av dei er ein direkte ekvivalent til ein RRAS VM berre fordi han kan avslutte IPsec: NAT-modellen og eigarskapet til ruter og designet for høg tilgjenge avgjer korleis eksisterande stader koplar til og kvar svara deira kjem tilbake. Score kvar kandidat på papir mot lista og skriv ned kva krav han ikkje oppfyller, fordi den nota er det som gjer valet gjennomgåeleg seinare.

Ein lastbalansar framfor to appliance-VM-ar er ikkje høg tilgjenge i seg sjølv. Han leverer ein front end, ikkje synkronisert tunnelstatus, og eit failover som droppar kvar sesjon, er eit designval nokon må ta med vilje. Spør appliance-leverandøren kva støtta HA-mønster som gjeld, og om det samsvarar med tilgjenge som stadene fekk lova. Test failover før dei stadene er avhengige av det, og handsam kvar tapt sesjon som eit funn og ikkje ei overrasking.

Der kravet er verkeleg enkelt — éin stad, eitt prefiks, inga overlapping — vinn ei styrt teneste vanlegvis på driftskostnad. Der omsetjing og dynamisk ruting båe er i spel, kan appliance-vegen vere den einaste passande, og det er grunnen til å planleggje ein lengre migrasjon i staden for å behalde den ikkje-støtta VM-en.

Viss ein RRAS VM allereie køyrer

Oppdaging er ikkje grunn til å slette han. Planlegg endringa rundt avhengnadene den VM-en har samla: ruter andre subnett er avhengige av, NAT-reglar som skjuler kjeldeadresser, og alt overvakinga har lært å vente av adressa hans. Behald dei naudsynte rutene og ein testa gjenopprettingsveg medan det støtta målet blir designa og validert ved sida av.

Hald støttbarheit og teknisk diagnose som separate funn heile vegen. Ei ikkje-støtta ordning kan også ha ein vanleg rutingfeil, og å rette den feilen endrar ikkje støttestatusen. Båe utsegnene høyrer heime i rapporten, og ingen av dei opphevar den andre.

Avslutt gjennomgangen med å registrere støttesitatet, kravlista, den valde erstatninga og rekkjefølgja for overgangen. Dei fire punkta er det ein revisor eller eit nytt teammedlem først vil spørje om.