Un VNet Azure appairé a-t-il besoin de sa propre passerelle VPN ?

Un nouveau VNet spoke apparaît, le hub dispose déjà d’une passerelle site à site opérationnelle, et la question évidente est de savoir si vous devez payer une seconde passerelle. En général non : le transit de passerelle permet au spoke de consommer la passerelle du hub via l’appairage. Trois conditions décident si cela fonctionnera, et aucune n’est visible sur le badge d’état de l’appairage. La connectivité de l’appairage et l’autorisation d’utiliser la passerelle d’un autre sont des réglages distincts, donc deux VM qui peuvent déjà se pinguer ne prouvent rien sur le chemin VPN.

Première condition : la passerelle, et l’absence de passerelle dans le spoke

Azure prend en charge le transit de passerelle pour les référence SKU VPN Gateway autres que Basic, et l’appairage régional comme mondial peut le transporter. Le spoke consomme une passerelle qu’il ne possède pas, il ne peut donc pas en avoir une à lui : si une passerelle existe déjà dans le spoke, ou si une option de passerelle distante est déjà sélectionnée, le réglage de transit souhaité sera indisponible ou sans effet. Vérifiez-le avant de déboguer quoi que ce soit, car la case grisée est le symptôme, pas la panne. Lisez d’abord la référence SKU et la passerelle existante, puis regardez les réglages de l’appairage.

Ne supprimez pas une passerelle spoke existante pour faire apparaître l’option tant que vous ne savez pas ce qui en dépend. L’ordre de migration compte plus que la case à cocher.

Deuxième condition : un réglage dans chaque sens de l’appairage

Un appairage, ce sont deux objets, un sur chaque VNet, et les réglages de transit vivent de part et d’autre de cette paire. L’appairage du hub vers le spoke doit autoriser la passerelle du hub à desservir le spoke ; l’appairage du spoke vers le hub doit accepter la passerelle du hub. le guide du transit de passerelle de Microsoft les nomme par sens, ce qui est la seule façon de les garder justes :

Un contrôle étiqueté remote change de sens selon l’appairage de quel VNet vous modifiez, lisez donc la direction, pas le mot. Réglez les deux côtés, enregistrez et confirmez que l’appairage signale une connexion aux deux endroits.

Troisième condition : espace d’adressage et limites d’autorisations

Le transit ne peut pas faire signifier deux réseaux au même préfixe de destination, les plages du hub, du spoke et du réseau local doivent donc être disjointes avant que tout cela ne fonctionne. Les VNet peuvent aussi se trouver dans des abonnements ou des locataires différents ; ce n’est pas une interdiction, mais l’identité qui crée ou met à jour chaque appairage a besoin des autorisations requises sur ce réseau. Les changements entre abonnements échouent souvent sur les autorisations, et l’erreur se lit facilement à tort comme un problème de topologie.

Notez les plages et les propriétaires avant le changement. Deviner l’un ou l’autre produit un appairage qui se connecte et ne route rien.

Vérifiez avec les itinéraires effectifs, pas avec l’état de l’appairage

Regardez les itinéraires effectifs sur l’interface réseau d’une charge de travail du spoke et trouvez le préfixe local réel. Vérifiez la table de routage du sous-réseau et si la propagation des itinéraires de passerelle est désactivée, car un itinéraire défini par l’utilisateur ou un équipement d’inspection peut supplanter le chemin que suggèrent les indicateurs de l’appairage. Confirmez ensuite l’autre sens : le réseau local doit savoir comment atteindre le préfixe du spoke via la connexion site à site, que ce soit par des annonces apprises ou par un itinéraire explicite et une entrée de réseau protégé correspondante sur l’équipement du client. Si le préfixe manque d’un côté ou de l’autre, les indicateurs de l’appairage ne sont pas ce qu’il faut changer.

Testez un service depuis une charge de travail du spoke et suivez la réponse. Un test depuis la passerelle VPN ou depuis une VM du hub exerce un préfixe source et un chemin différents.

Si la topologie sert aussi des clients point à site, validez séparément leurs itinéraires installés. Les packages clients Windows peuvent nécessiter une régénération après un changement de topologie, et c’est une tâche de routage côté client, non la preuve que le partage de passerelle a échoué.

Ce que le partage d’une passerelle n’accorde pas

Le transit de passerelle est une commodité de routage, pas une autorisation. Les groupes de sécurité réseau, les filtres locaux et les règles de niveau service décident toujours ce qu’une charge de travail du spoke peut atteindre, activez donc le service précis de la source vers la destination au lieu de supposer que le tunnel partagé autorise tout ce qui se trouve derrière.

L’appairage n’est pas non plus transitif comme on l’espère. L’ajout d’un autre spoke, ou d’un point de terminaison privé, introduit ses propres exigences de routage et d’accès que le réglage de transit existant ne couvre pas.