RRAS sur une VM Azure n'est pas pris en charge : vérifiez avant de concevoir

Vous ouvrez le portail, déployez Windows Server 2022 dans un sous-réseau, et le rôle Remote Access s'installe proprement. Cette séquence prouve que le programme d'installation fonctionne, pas que Microsoft prend en charge la configuration. Les consignes publiées de support des logiciels serveur pour les machines virtuelles Azure classent RRAS parmi les fonctionnalités de Windows Server qui ne sont pas prises en charge sur les VM Azure, et c'est une décision d'architecture, pas un détail de dépannage. Un tunnel qui monte ne déplace pas le déploiement à l'intérieur de la limite de support.

Le parcours ci-dessous commence sur la page de support, puis s'étend vers les exigences et les options de remplacement.

Commencez par la page de support, pas par le laboratoire

Lisez les consignes de support des VM Azure avant de dimensionner quoi que ce soit. Elles séparent les produits, rôles et fonctionnalités pris en charge au lieu de traiter Windows Server comme un bloc indifférencié. Repérez la ligne sous laquelle tombe réellement votre charge de travail prévue, car deux composants qui semblent liés dans la console peuvent siéger dans des lignes différentes.

Écrivez la citation dans le document de conception tant que la page est ouverte. Le statut de support est un fait avec une source, et une revue de conception qui ne peut pas le citer sera démolie par celui qui a la démo.

Séparez le support du système d'exploitation de celui des rôles et fonctionnalités

Ces mêmes consignes placent Network Policy and Access Services parmi les rôles pris en charge tout en listant RRAS séparément comme non pris en charge. Ces deux entrées décrivent des choses différentes, et les fusionner en « l'accès distant est pris en charge » est la façon dont un projet est approuvé sur une lecture erronée. Le fait que le système d'exploitation soit pris en charge ne dit rien d'une fonctionnalité qui a sa propre ligne.

La limitation est aussi plus étroite qu'on ne la cite parfois. Elle concerne cette fonctionnalité exécutée dans une VM Azure ; elle ne signifie pas qu'un réseau privé ne peut pas se connecter à Azure, et elle ne dit pas que RRAS n'est pris en charge nulle part. Un ancien laboratoire qui achemine correctement les paquets est une preuve sur les paquets, pas sur la déclaration de support.

Gardez ces deux questions séparées pour le reste du projet : cela fonctionne-t-il, et est-ce pris en charge. Vous aurez besoin de réponses différentes et parfois de responsables différents pour chacune.

Écrivez ce que la conception doit réellement faire

Avant de choisir un remplacement, transformez la liste des sites en exigences auxquelles un produit peut être mesuré :

• Les protocoles de tunnel que les équipements des agences parlent déjà, et si un site a besoin de routage dynamique.
• Les préfixes distants, y compris tout espace d'adressage qui se chevauche et nécessite une traduction plutôt qu'un routage.
• L'échange de routes avec Azure, et qui possède chaque entrée de la table de routage.
• Le débit et le nombre de connexions que l'heure la plus chargée doit soutenir.
• Le comportement de basculement convenu par les propriétaires des sites, pas seulement celui que vous pouvez construire.

NAT est l'élément que l'on saute et qui décide ensuite de toute la conception. Un équipement capable d'établir IPsec peut encore traduire les adresses différemment du déploiement RRAS qu'il remplace, ce qui change ce que l'agence voit comme adresses source et ce que vos journaux enregistrent.

Portez la liste aux responsables réseau et confirmez-la avant toute discussion produit. Des exigences ambiguës transforment toute comparaison de fournisseurs en débat de préférences.

Évaluez les remplacements au regard de ces exigences

Les services de connectivité gérés d'Azure et les appliances virtuelles réseau prises en charge par les fournisseurs doivent tous deux être notés sur la même liste. Ne supposez pas que l'un ou l'autre est un équivalent direct d'une VM RRAS simplement parce qu'il peut terminer IPsec : le modèle NAT et la propriété des routes ainsi que la conception de haute disponibilité décident comment les sites existants se connectent et où leurs réponses reviennent. Notez chaque candidat sur papier par rapport à la liste et écrivez quelles exigences il ne satisfait pas, car c'est cette note qui rend le choix révisable plus tard.

Un répartiteur de charge devant deux VM d'appliance n'est pas en soi de la haute disponibilité. Il fournit un front-end, pas un état de tunnel synchronisé, et un basculement qui abandonne chaque session est un choix de conception que quelqu'un doit faire exprès. Demandez au fournisseur de l'appliance quel est le modèle HA pris en charge et s'il correspond à la disponibilité promise aux sites. Testez le basculement avant que ces sites en dépendent, et traitez chaque session perdue comme une constatation plutôt qu'une surprise.

Là où l'exigence est vraiment simple — un site, un préfixe, pas de chevauchement — un service géré l'emporte généralement sur le coût d'exploitation. Là où la traduction et le routage dynamique sont tous deux en jeu, la voie de l'appliance peut être la seule adaptée, et c'est une raison de planifier une migration plus longue plutôt que de garder la VM non prise en charge.

Si une VM RRAS tourne déjà

La découverte n'est pas une raison de la supprimer. Planifiez le changement autour des dépendances que cette VM a accumulées : routes sur lesquelles d'autres sous-réseaux comptent, règles NAT qui masquent les adresses source, et tout ce que la supervision a appris à attendre de son adresse. Préservez les routes nécessaires et un chemin de récupération testé pendant que la cible prise en charge est conçue et validée à côté.

Gardez la supportabilité et le diagnostic technique comme des constatations distinctes tout du long. Une configuration non prise en charge peut aussi avoir une erreur de routage ordinaire, et corriger cette erreur ne change pas son statut de support. Les deux affirmations appartiennent au rapport, et aucune n'annule l'autre.

Clôturez le parcours en consignant la citation de support, la liste des exigences, le remplacement choisi et l'ordre de bascule. Ces quatre éléments sont ce qu'un auditeur ou un nouveau membre d'équipe demandera en premier.