UDR Azure vers une passerelle VPN : une destination, pas toute la sortie

Vous ajoutez une route définie par l'utilisateur pour un préfixe externe, vous la pointez vers la passerelle VPN, et le trafic sort toujours par le chemin Internet d'Azure. Ou bien il sort correctement et la réponse ne revient jamais. Ces deux issues viennent de la même erreur : considérer le prochain saut Azure comme tout le design. La table de routes décide seulement quelle sortie un paquet prend dans Azure. Ce qui lui arrive après le tunnel, et comment la réponse revient, est une seconde moitié que vous devez construire.

Le prochain saut est une passerelle, pas l'IP d'un équipement

Une UDR envoie un préfixe correspondant à un type de prochain saut, et VirtualNetworkGateway est un type, pas une adresse. Les gens collent l'IP privée de la passerelle dans une route VirtualAppliance puis se demandent pourquoi rien ne correspond, car ce type attend une carte réseau ou un équilibreur de charge interne. La documentation de routage de Microsoft limite aussi le prochain saut de passerelle à un réseau virtuel dont la passerelle est une passerelle VPN. ExpressRoute, Route Server et un hub Virtual WAN ne sont pas adressés par cette option.

Vérifiez ce que le réseau virtuel possède réellement avant d'écrire la route. Si le design route via un hub, la route appartient au propriétaire du routage du hub, pas au spoke que vous modifiez par hasard.

Lisez la route effective avant de modifier quoi que ce soit

Azure combine les routes système, les préfixes appris par BGP et les UDR dans une table de routes effective par carte réseau, et le préfixe correspondant le plus long gagne, d'où qu'il vienne. Pour un même préfixe, une UDR l'emporte sur une route BGP. Cet ordre explique pourquoi une UDR obsolète d'une expérience précédente peut écraser silencieusement le préfixe que vous venez d'apprendre par le tunnel.

Regardez d'abord la table effective, puis décidez si vous ajoutez une route ou en remplacez une :

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Lisez aussi la colonne source, pas seulement le préfixe. Une route avec le bon préfixe et la mauvaise source vous indique quel objet modifier, et vous évite d'ajouter une seconde route qui perd contre la première.

Écrivez la route sur le préfixe et le sous-réseau réels

Utilisez le préfixe réel de la destination, tiré du service que vous atteignez vraiment, plutôt qu'une plage publique copiée d'un message de forum. Commencez par un service approuvé avant d'envisager une route par défaut qui déplace toute la sortie. Attachez ensuite la table de routes au sous-réseau de la charge de travail. Le sous-réseau de passerelle a ses propres exigences, et y attacher votre table casse la passerelle au lieu de diriger la charge.

Créez la route, puis liez la table au sous-réseau qui héberge la charge :

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

La propagation compte aussi. Avec la propagation BGP activée sur cette table, les préfixes appris apparaissent à côté de ceux que vous avez écrits, et un préfixe appris plus spécifique peut l'emporter sur une UDR plus large. Ne désactivez la propagation que lorsque vous voulez que le jeu d'UDR fasse autorité pour ce sous-réseau.

Terminez la moitié locale, sinon le flux meurt là

La passerelle locale doit accepter la source Azure, la transmettre à la destination et autoriser l'application. Son chemin ensuite peut être une sortie Internet ou un autre saut privé, mais cette décision relève du plan et non de la table de routes Azure. L'échec habituel est le retour. Une destination Internet ne routrera pas une source privée Azure vers vous, donc la réponse part vers sa propre passerelle par défaut et meurt, ou ne sort jamais.

Deux designs règlent cela et ils ne sont pas interchangeables. Traduisez la source à la sortie, afin que la destination réponde à une adresse publique que le réseau local possède. Ou conservez la source et construisez une relation de retour routée pour que les réponses reviennent par le tunnel. Choisissez l'un et notez quelle adresse l'application verra.

Les sélecteurs et les listes d'autorisation sont distincts de tout cela. Choisir un prochain saut Azure n'élargit pas les sélecteurs de trafic VPN et ne change pas la liste d'autorisation de sources d'un service externe.

Vérifiez avec la source observée par la destination

Envoyez la requête depuis la charge réelle plutôt que depuis un hôte de saut dans un autre sous-réseau, puis lisez l'adresse source observée par la destination. Cette seule valeur vous dit lequel des deux designs de retour est en place. Vérifiez ensuite le chemin de réponse et confirmez que le trafic de gestion ordinaire vers la VM fonctionne toujours, car une route par défaut ajoutée par accident se manifeste comme une session SSH cassée bien avant de se manifester comme une application cassée.

Un transit par préfixe sélectionné est un changement bien plus étroit que le tunnel forcé. Gardez-le étroit et le retour arrière consiste à supprimer une route.