Configurer GatewaySubnet dans Azure : réservez-le avant la passerelle

Ouvrez le réseau virtuel dans le portail et examinez l’espace d’adressage avant de toucher au panneau du sous-réseau. Si ce /24 est déjà découpé en sous-réseaux de charge de travail sans rien de libre, il n’y a pas de place pour une réservation /27, et vous finirez soit par redécouper, soit par élargir le VNet, ce qui est un autre changement avec une autre revue. Réglez d’abord l’espace, puis créez le sous-réseau.

Cet ordre compte parce que le sous-réseau de passerelle n’est pas un sous-réseau de charge de travail avec un nom spécial. C’est la réservation d’adresses pour les instances de passerelle gérées, et Azure refusera la passerelle si la réservation est erronée.

Commencez par l’espace d’adressage

Écrivez le préfixe du VNet, les sous-réseaux de charge de travail et la réservation de passerelle sur une seule ligne avant de saisir quoi que ce soit. Un VNet en 10.60.0.0/16 a de la place ; choisissez une plage à la fin pour que la croissance des charges de travail reste contiguë.

Par exemple, 10.60.255.192/26 laisse 64 adresses pour la passerelle tandis que les charges de travail restent en 10.60.0.0/20. C’est un exemple de planification d’adresses, pas une promesse de dimensionnement. Microsoft exige actuellement /27 ou plus grand pour les passerelles VPN non Basic, où plus grand signifie plus d’adresses : un /26 en donne 64, tandis qu’un /28 en donne 16. Arrondissez vers le haut, jamais vers le bas, tant que le plan d’adressage bouge encore.

Créez le sous-réseau avec le nom exact

Dans le portail, ajoutez un sous-réseau et tapez le nom GatewaySubnet exactement, G majuscule et S majuscule, sans espace ni suffixe. Azure compare cette chaîne, donc Gateway-Subnet ou gateway produit un sous-réseau que le service de passerelle n’utilisera pas.

La même étape en CLI, plus facile à inscrire dans une revue :

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

Laissez le sous-réseau vide. Pas de VM, pas de point de terminaison privé, pas de délégation de service. Si quelque chose y vit déjà, le déploiement échoue et l’erreur nomme rarement la ressource qui gêne, alors vérifiez la liste des ressources du sous-réseau avant de commencer.

Gardez le sous-réseau géré exempt de règles de charge de travail

N’attachez pas de groupe de sécurité réseau à ce sous-réseau ; Microsoft le marque comme non pris en charge. N’associez pas de table de routage dont la route par défaut envoie 0.0.0.0/0 quelque part, car cela peut casser le fonctionnement de la passerelle, et gardez la propagation des routes de passerelle activée.

Placez les restrictions d’accès que vous vouliez vraiment sur le sous-réseau de charge de travail ou à une frontière d’inspection. Traiter GatewaySubnet comme un sous-réseau ordinaire est l’erreur qui produit une passerelle qui se déploie proprement puis ne fait passer aucun trafic.

Le tunneling forcé a son propre design documenté. Une route par défaut improvisée sur le sous-réseau de passerelle n’en est pas un.

Vérifiez les dépendances que le portail ne montre pas

Avant d’appuyer sur créer, parcourez la liste : nom exact, préfixe à l’intérieur de l’espace du VNet, aucun chevauchement avec les plages locales, aucune ressource de charge de travail à l’intérieur, aucun NSG et aucune table de routage avec une route par défaut. Chacun de ces points a cassé un déploiement réel. Confirmez ensuite la conception plus large : la passerelle de réseau local pour le côté local, les espaces d’adressage que vous comptez router, et si un mode actif-actif ou une coexistence est prévu. Ces choix changent la conversation sur le dimensionnement, et il est bien moins coûteux de les régler maintenant.

La référence des paramètres de passerelle Azure est la page à citer quand quelqu’un demande pourquoi le sous-réseau ne peut pas héberger une VM.

Si la passerelle existe déjà

Redimensionner ou remplacer un sous-réseau de passerelle n’est pas une modification de masque. Vérifiez d’abord la procédure de changement prise en charge pour la référence et la génération de la passerelle, et listez les objets dépendants : connexions, IP publiques, routage et toute exigence de reprise.

Si la procédure impose de recréer la passerelle, planifiez-le comme une migration de service avec une fenêtre et un retour arrière. Notez la réservation choisie, la raison de la taille et les règles que vous n’avez délibérément pas attachées, pour que le prochain relecteur ne répare pas le sous-réseau vide en ajoutant un NSG.