RRAS su una VM Azure non è supportato: verificate prima del progetto

Aprite il portale, distribuite Windows Server 2022 in una subnet e il ruolo Remote Access si installa senza problemi. Questa sequenza dimostra che il programma di installazione funziona, non che Microsoft supporti la configurazione. Le linee guida pubblicate sul supporto del software server per le macchine virtuali Azure elencano RRAS tra le funzionalità di Windows Server non supportate sulle VM Azure, e questa è una decisione architetturale, non un dettaglio di risoluzione dei problemi. Un tunnel che si alza non sposta la distribuzione dentro il confine del supporto.

Il percorso seguente inizia dalla pagina di supporto, poi si estende verso i requisiti e le opzioni di sostituzione.

Iniziate dalla pagina di supporto, non dal laboratorio

Leggete le linee guida di supporto per le VM Azure prima di dimensionare qualcosa. Separano prodotti, ruoli e funzionalità supportati invece di trattare Windows Server come un blocco indifferenziato. Notate in quale riga ricade realmente il carico di lavoro previsto, perché due componenti che nella console sembrano correlati possono trovarsi in righe diverse.

Scrivete la citazione nel documento di progetto mentre la pagina è aperta. Lo stato di supporto è un fatto con una fonte, e una revisione di progetto che non può citarlo sarà smontata da chi ha la demo.

Separate il supporto del sistema operativo da quello di ruoli e funzionalità

Le stesse linee guida elencano Network Policy and Access Services tra i ruoli supportati mentre elencano RRAS separatamente come non supportato. Queste due voci descrivono cose diverse, e fonderle in «l'accesso remoto è supportato» è il modo in cui un progetto viene approvato su una lettura sbagliata. Il fatto che il sistema operativo sia supportato non dice nulla su una funzionalità che ha una propria riga.

La limitazione è anche più stretta di quanto talvolta venga citata. Riguarda quella funzionalità in esecuzione all'interno di una VM Azure; non significa che una rete privata non possa connettersi ad Azure, né dice che RRAS non sia supportato ovunque. Un vecchio laboratorio che inoltra correttamente i pacchetti è una prova sui pacchetti, non sulla dichiarazione di supporto.

Tenete separate queste due domande per il resto del progetto: funziona ed è supportato. Vi serviranno risposte diverse e talvolta responsabili diversi per ciascuna.

Scrivete cosa deve fare realmente il progetto

Prima di scegliere una sostituzione, trasformate l'elenco dei siti in requisiti su cui misurare un prodotto:

• I protocolli di tunnel che i dispositivi delle filiali parlano già, e se qualche sito necessita di routing dinamico.
• I prefissi remoti, compreso qualsiasi spazio di indirizzi sovrapposto che richieda traduzione anziché routing.
• Lo scambio di rotte con Azure, e chi possiede ogni voce della tabella di routing.
• La capacità e il numero di connessioni che l'ora più carica deve sostenere.
• Il comportamento di failover concordato dai proprietari dei siti, non solo quello che potete costruire.

NAT è l'elemento che viene saltato e poi decide l'intero progetto. Un dispositivo in grado di stabilire IPsec può comunque tradurre gli indirizzi in modo diverso dalla distribuzione RRAS che sostituisce, e questo cambia ciò che la filiale vede come indirizzi di origine e ciò che i vostri log registrano.

Portate l'elenco ai responsabili della rete e confermatelo prima di qualsiasi discussione sui prodotti. Requisiti ambigui trasformano ogni confronto tra fornitori in una discussione di preferenze.

Valutate le sostituzioni rispetto a quei requisiti

I servizi di connettività gestiti di Azure e le appliance virtuali di rete supportate dai fornitori devono entrambi essere valutati rispetto allo stesso elenco. Non date per scontato che uno dei due sia un equivalente diretto di una VM RRAS solo perché può terminare IPsec: il modello NAT e la proprietà delle rotte e il progetto di alta disponibilità decidono come si connettono i siti esistenti e dove tornano le loro risposte. Valutate ogni candidato sulla carta rispetto all'elenco e annotate quali requisiti non soddisfa, perché quella nota è ciò che rende la scelta riesaminabile in seguito.

Un bilanciatore di carico davanti a due VM appliance non è alta disponibilità di per sé. Fornisce un front-end, non uno stato dei tunnel sincronizzato, e un failover che lascia cadere ogni sessione è una scelta di progetto che qualcuno deve fare di proposito. Chiedete al fornitore dell'appliance qual è il modello HA supportato e se corrisponde alla disponibilità promessa ai siti. Testate il failover prima che quei siti ne dipendano, e trattate ogni sessione persa come un riscontro e non come una sorpresa.

Dove il requisito è davvero semplice — un sito, un prefisso, nessuna sovrapposizione — un servizio gestito di solito vince sul costo operativo. Dove traduzione e routing dinamico sono entrambi in gioco, la via dell'appliance può essere l'unica adatta, e questo è un motivo per pianificare una migrazione più lunga invece di tenere la VM non supportata.

Se una VM RRAS è già in esecuzione

La scoperta non è un motivo per eliminarla. Pianificate il cambiamento attorno alle dipendenze che quella VM ha accumulato: rotte su cui contano altre subnet, regole NAT che nascondono gli indirizzi di origine e tutto ciò che il monitoraggio ha imparato ad aspettarsi dal suo indirizzo. Preservate le rotte necessarie e un percorso di ripristino testato mentre la destinazione supportata viene progettata e validata accanto.

Tenete la supportabilità e la diagnosi tecnica come riscontri separati per tutto il tempo. Una configurazione non supportata può anche avere un normale errore di routing, e correggere quell'errore non cambia il suo stato di supporto. Entrambe le affermazioni appartengono al rapporto, e nessuna delle due annulla l'altra.

Chiudete il percorso registrando la citazione di supporto, l'elenco dei requisiti, la sostituzione scelta e l'ordine di passaggio. Quei quattro elementi sono la prima cosa che un revisore o un nuovo membro del team chiederà.