RRAS på en Azure VM stöds inte: kontrollera före design

Du öppnar portalen, distribuerar Windows Server 2022 i ett undernät och Remote Access-rollen installeras utan problem. Den sekvensen bevisar att installationsprogrammet fungerar, inte att Microsoft stöder konfigurationen. Den publicerade supportvägledningen för serverprogramvara för Azure-virtuella maskiner listar RRAS bland de Windows Server-funktioner som inte stöds på Azure VM, och det är ett arkitekturbeslut, inte en felsökningsdetalj. En tunnel som kommer upp flyttar inte distributionen innanför supportgränsen.

Genomgången nedan börjar på supportsidan och arbetar sig sedan utåt mot krav och ersättningsalternativ.

Börja på supportsidan, inte i labbet

Läs supportvägledningen för Azure VM innan du dimensionerar något. Den skiljer stödda produkter, roller och funktioner i stället för att behandla Windows Server som ett odifferentierat block. Notera vilken rad den planerade arbetsbelastningen faktiskt hör under, eftersom två komponenter som ser besläktade ut i konsolen kan stå i olika rader.

Skriv in citatet i designdokumentet medan sidan är öppen. Supportstatus är ett faktum med en källa, och en designgranskning som inte kan citera den kommer att pratas ned av den som har demon.

Skilj OS-stöd från stöd för roller och funktioner

Samma vägledning listar Network Policy and Access Services bland stödda roller medan RRAS listas separat som ej stött. De två posterna beskriver olika saker, och att slå ihop dem till ”fjärråtkomst stöds” är hur ett projekt godkänns på en felläsning. Att operativsystemet stöds säger ingenting om en funktion som har sin egen rad.

Begränsningen är också snävare än den ibland citeras. Den gäller den funktionen som körs inuti en Azure VM; den betyder inte att ett privat nätverk inte kan ansluta till Azure, och den säger inte att RRAS inte stöds överallt. Ett äldre labb som vidarebefordrar paket korrekt är bevis om paket, inte om supportuttalandet.

Håll de två frågorna åtskilda resten av projektet: fungerar det, och stöds det. Du behöver olika svar och ibland olika ägare för vart och ett.

Skriv ned vad designen faktiskt måste göra

Innan du väljer en ersättning, förvandla platslistan till krav som en produkt kan mätas mot:

• Tunnelprotokollen som filialernas enheter redan talar, och om någon plats behöver dynamisk routing.
• Fjärrprefixen, inklusive eventuellt överlappande adressutrymme som kräver översättning i stället för routing.
• Rututbyte med Azure, och vem som äger varje post i routingtabellen.
• Genomströmning och antal anslutningar som den mest trafikerade timmen måste klara.
• Failoverbeteendet som platsägarna har kommit överens om, inte bara det du kan bygga.

NAT är posten som hoppas över och sedan avgör hela designen. En enhet som kan upprätta IPsec kan fortfarande översätta adresser annorlunda än den RRAS-distribution den ersätter, och det ändrar vad filialen ser som källadresser och vad dina loggar registrerar.

Ta listan till nätägarna och bekräfta den före någon produktdiskussion. Tvetydiga krav gör varje leverantörsjämförelse till en preferensdebatt.

Utvärdera ersättningar mot dessa krav

Azures hanterade anslutningstjänster och leverantörsstödda virtuella nätverksenheter måste båda poängsättas mot samma lista. Anta inte att någon av dem är en direkt motsvarighet till en RRAS VM bara för att den kan avsluta IPsec: NAT-modellen och ägarskapet av rutter och designen för hög tillgänglighet avgör hur befintliga platser ansluter och vart deras svar återvänder. Poängsätt varje kandidat på papper mot listan och skriv ned vilka krav den inte uppfyller, eftersom den anteckningen gör valet granskningsbart senare.

En lastbalanserare framför två appliance-VM:er är inte hög tillgänglighet i sig. Den ger en front end, inte synkroniserad tunnelstatus, och en failover som tappar varje session är ett designval som någon måste göra med avsikt. Fråga appliance-leverantören vilket HA-mönster som stöds och om det matchar den tillgänglighet som platserna utlovades. Testa failovern innan dessa platser är beroende av den, och behandla varje förlorad session som en iakttagelse och inte som en överraskning.

Där kravet är riktigt enkelt — en plats, ett prefix, ingen överlappning — vinner en hanterad tjänst oftast på driftskostnad. Där översättning och dynamisk routing båda är i spel kan appliance-vägen vara den enda lämpliga, och det är ett skäl att planera en längre migrering i stället för att behålla den icke stödda VM:en.

Om en RRAS VM redan körs

Upptäckt är inte ett skäl att radera den. Planera ändringen kring de beroenden som den VM:en har samlat: rutter som andra undernät förlitar sig på, NAT-regler som döljer källadresser, och allt som övervakningen har lärt sig förvänta sig av dess adress. Behåll de nödvändiga rutterna och en testad återställningsväg medan det stödda målet designas och valideras bredvid.

Håll stödbarhet och teknisk diagnostik som separata iakttagelser hela tiden. En icke stödd ordning kan också ha ett vanligt routingfel, och att åtgärda det felet ändrar inte dess supportstatus. Båda uttalandena hör hemma i rapporten, och ingen av dem upphäver den andra.

Avsluta genomgången med att registrera supportcitatet, kraven, den valda ersättningen och ordningen för övergången. De fyra punkterna är det en revisor eller en ny teammedlem först kommer att fråga efter.