Acheminer le trafic entre deux sites via une passerelle VPN Azure
Deux connexions site à site sur une même passerelle VPN Azure peuvent faire passer le trafic des sites, mais seulement lorsque les deux extrémités apprennent le préfixe et que le chemin de retour LAN existe.
Deux sites peuvent échanger du trafic via une passerelle VPN Azure sans aucun tunnel direct entre eux. Chaque site ouvre une connexion site à site vers la même passerelle, et la passerelle transmet les préfixes appris entre les deux connexions. Ce qui fait fonctionner cela n’est pas le second tunnel mais l’échange de routes : le site A doit apprendre le préfixe du site B, et B celui de A. Parcourez les vérifications ci-dessous dans l’ordre et arrêtez-vous à la première qui échoue, car chaque étape suivante en dépend.
Prérequis, avant de configurer quoi que ce soit
Quatre conditions décident si cette conception peut fonctionner. La passerelle doit être basée sur les routes et sur une SKU qui prend en charge BGP, les deux connexions doivent avoir BGP activé, les espaces d’adressage des sites ne doivent pas se chevaucher, et aucun côté ne doit compter sur NAT pour masquer son préfixe réel.
Planifiez les ASN avec soin. La valeur par défaut documentée d’Azure est 65515, et chaque routeur de site a besoin de son propre ASN privé qui n’entre pas en collision avec la passerelle ni avec l’autre site. Réutiliser une valeur par défaut sans vérifier une configuration de passerelle existante est la façon dont un chemin AS finit par être rejeté plus tard.
Confirmez aussi que vous n’attendez pas le comportement d’appairage VNet. La passerelle échange des routes entre les deux connexions que vous avez configurées ; elle ne rend pas transitifs des appairages arbitraires. Si un troisième réseau doit atteindre les deux sites, il a besoin de sa propre connexion ou de son propre chemin de route, pas de la supposition que la passerelle répartira le trafic. Écrivez cette limite avant la première fenêtre de changement, car c’est la décision de conception à laquelle les gens reviennent lorsqu’un site est ajouté plus tard.
Configurez dans cet ordre
Chaque étape a un résultat observable, donc n’avancez pas tant qu’il n’apparaît pas.
- Activez BGP sur la passerelle de réseau virtuel et notez son ASN et son adresse de pair.
- Créez une passerelle de réseau local par site avec l’espace d’adressage réel de ce site, son ASN et son adresse de pair BGP.
- Créez chaque connexion site à site et activez BGP sur la connexion elle-même.
- Configurez le routeur du site pour s’appairer avec l’adresse de passerelle attribuée par Azure, pas avec le point de terminaison IKE public de la passerelle par supposition.
La quatrième étape est celle où la plupart des tentatives calent. L’adresse de pair BGP qu’Azure signale est celle que le routeur du site doit utiliser comme voisin, et ce n’est pas toujours l’adresse que les gens attendent du schéma du tunnel.
Annoncez le préfixe du site lui-même, par exemple 10.10.0.0/16 depuis A et 10.20.0.0/16 depuis B. N’annoncez pas une route par défaut ni un agrégat large pour couvrir un réseau spécifique manquant ; le trou revient plus tard sous forme de trou noir silencieux.
Vérifiez l’échange de routes aux deux extrémités
L’état de la connexion n’est pas la vérification. IPsec peut être actif sur les deux connexions alors qu’aucun préfixe ne passe entre elles. Lisez les pairs BGP de la passerelle et ses routes apprises, puis confirmez que la route vers l’autre site apparaît comme un chemin utilisable.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Un préfixe présent dans une table BGP peut encore perdre la décision de transfert face à une route statique ou à un préfixe plus spécifique. Vérifiez la route sélectionnée, pas seulement celle reçue.
Suivez le chemin de retour côté LAN
C’est la partie qui semble correcte dans Azure et qui échoue sur le site. Un hôte du site A n’envoie son paquet au routeur VPN de A que si ce routeur est sa passerelle par défaut, ou si l’hôte ou sa passerelle détient une route pour le préfixe de B. La même chose doit être vraie dans l’autre sens.
Si un commutateur central distinct est la passerelle par défaut du LAN, il a besoin de la route vers l’autre site pointant vers le routeur VPN. Sans elle, la requête arrive et la réponse sort par le chemin Internet, et l’utilisateur voit une connexion qui s’ouvre puis se bloque.
Ne vous tournez pas vers un groupe de sécurité réseau sur le sous-réseau de la passerelle pour corriger cela. Ce sous-réseau a ses propres exigences, et un NSG à cet endroit n’est pas un substitut pris en charge à la politique côté site. Le filtrage appartient aux pare-feu des sites et aux charges de travail elles-mêmes, où les règles peuvent être revues par les personnes qui les possèdent. Déplacer ces règles vers un NSG de sous-réseau les cache aussi de l’équipe qui déboguera la prochaine panne.
Autorisez l’opération, puis prouvez-la par un test refusé
Une route apprise n’est pas une autorisation. Autorisez la source, la destination et le service dont vous avez réellement besoin via les pare-feu des sites et la politique du point de terminaison, et laissez le reste refusé.
Testez depuis une charge de travail ordinaire du site A vers un service réel du site B, confirmez la réponse, puis tentez une opération qui doit rester interdite. Le trafic généré par l’appliance VPN elle-même peut utiliser une autre adresse source et sauter l’étape de routage LAN, donc un ping réussi depuis le routeur prouve moins qu’il n’y paraît.
Terminez en notant quatre faits : les préfixes échangés, les ASN utilisés, le chemin de retour LAN de chaque côté et la politique qui autorise le service. S’il en manque un, la configuration fonctionne jusqu’au premier changement, puis personne ne peut expliquer pourquoi.