RRAS på en Azure VM understøttes ikke: tjek før designet

Du åbner portalen, udruller Windows Server 2022 i et undernet, og Remote Access-rollen installeres uden problemer. Den sekvens beviser, at installationsprogrammet virker, ikke at Microsoft understøtter konfigurationen. Den offentliggjorte supportvejledning for serversoftware til Azure-virtuelle maskiner lister RRAS blandt de Windows Server-funktioner, der ikke understøttes på Azure VM'er, og det er en arkitekturbeslutning snarere end en fejlfindingsdetalje. En tunnel, der kommer op, flytter ikke udrulningen inden for supportgrænsen.

Gennemgangen nedenfor starter på supportsiden og arbejder derefter udad mod krav og udskiftningsmuligheder.

Start på supportsiden, ikke i laboratoriet

Læs supportvejledningen for Azure VM'er, før du dimensionerer noget. Den adskiller understøttede produkter, roller og funktioner i stedet for at behandle Windows Server som én udifferentieret blok. Bemærk, hvilken række din tilsigtede arbejdsbelastning faktisk hører under, fordi to komponenter, der ser beslægtede ud i konsollen, kan stå i forskellige rækker.

Skriv citatet ind i designdokumentet, mens siden er åben. Supportstatus er et faktum med en kilde, og et designreview, der ikke kan citere den, vil blive talt ned af den, der har demoen.

Adskil OS-support fra rolle- og funktionssupport

Samme vejledning lister Network Policy and Access Services blandt understøttede roller, mens RRAS listes særskilt som ikke understøttet. De to poster beskriver forskellige ting, og at slå dem sammen til „fjernadgang understøttes“ er, hvordan et projekt bliver godkendt på en fejllæsning. At operativsystemet understøttes siger intet om en funktion, der har sin egen række.

Begrænsningen er også snævrere, end den nogle gange citeres. Den handler om den funktion, der kører inde i en Azure VM; den betyder ikke, at et privat netværk ikke kan forbinde til Azure, og den siger ikke, at RRAS ikke understøttes overalt. Et ældre laboratorium, der videresender pakker korrekt, er bevis om pakker, ikke om supportudtalelsen.

Hold de to spørgsmål adskilt resten af projektet: virker det, og understøttes det. Du får brug for forskellige svar og nogle gange forskellige ejere til hvert af dem.

Skriv ned, hvad designet faktisk skal gøre

Før du vælger en erstatning, skal du omdanne sitelisten til krav, som et produkt kan måles imod:

• Tunnelprotokoller, som grenenes enheder allerede taler, og om nogen site har behov for dynamisk routing.
• Fjerntliggende præfikser, herunder ethvert overlappende adresserum, der kræver oversættelse i stedet for routing.
• Ruteudveksling med Azure, og hvem der ejer hver post i rutetabellen.
• Gennemstrømning og antal forbindelser, som den travleste time skal holde.
• Failover-adfærd, som siteejerne har accepteret, ikke kun den, du kan bygge.

NAT er det punkt, der bliver sprunget over og derefter bestemmer hele designet. En enhed, der kan etablere IPsec, kan stadig oversætte adresser anderledes end den RRAS-udrulning, den erstatter, hvilket ændrer, hvad grenen ser som kilde-adresser, og hvad dine logs registrerer.

Tag listen med til netværksejerne, og bekræft den før enhver produktdiskussion. Tvetydige krav gør enhver leverandørsammenligning til et præferenceargument.

Vurder erstatninger mod disse krav

Azures administrerede connectivitytjenester og leverandørstøttede virtuelle netværksenheder skal begge scores mod den samme liste. Antag ikke, at nogen af dem er en direkte ækvivalent til en RRAS VM, blot fordi den kan terminere IPsec: NAT-modellen og ejerskabet af ruter og designet for høj tilgængelighed afgør, hvordan eksisterende sites forbinder, og hvor deres svar vender tilbage. Score hver kandidat på papir mod listen, og skriv ned, hvilke krav den ikke opfylder, fordi den note er det, der gør valget reviewbart senere.

En lastbalancer foran to appliance-VM'er er ikke høj tilgængelighed i sig selv. Den leverer en front end, ikke synkroniseret tunnelstatus, og et failover, der dropper hver session, er et designvalg, som nogen skal træffe med vilje. Spørg appliance-leverandøren, hvilket understøttet HA-mønster der gælder, og om det matcher den tilgængelighed, siterne blev lovet. Test failover, før de sites afhænger af det, og behandl hver tabt session som en konstatering frem for en overraskelse.

Hvor kravet er virkelig enkelt — ét site, ét præfiks, ingen overlapning — vinder en administreret tjeneste normalt på driftsomkostninger. Hvor oversættelse og dynamisk routing begge er i spil, kan appliance-vejen være den eneste passende, og det er grunden til at planlægge en længere migrering i stedet for at beholde den ikke-understøttede VM.

Hvis en RRAS VM allerede kører

Opdagelse er ikke en grund til at slette den. Planlæg ændringen omkring de afhængigheder, som den VM har samlet: ruter, som andre undernet er afhængige af, NAT-regler, der skjuler kildeadresser, og alt det, som overvågningen har lært at forvente af dens adresse. Bevar de nødvendige ruter og en testet gendannelsesvej, mens det understøttede mål designes og valideres sideløbende.

Hold supportabilitet og teknisk diagnose som separate konstateringer hele vejen. En ikke-understøttet opsætning kan også have en almindelig routingfejl, og at rette den fejl ændrer ikke dens supportstatus. Begge udsagn hører i rapporten, og ingen af dem ophæver den anden.

Afslut gennemgangen med at registrere supportcitatet, kravenes liste, den valgte erstatning og cutover-rækkefølgen. De fire ting er det, en revisor eller et nyt teammedlem først vil spørge om.