Deux adresses VPN locales : deux pairs Azure, pas un seul

Le schéma comporte deux liaisons Internet au niveau de l’agence et une passerelle VPN Azure, donc la passerelle de réseau local reçoit les deux adresses publiques. Cela semble propre et ne fonctionne pas comme le schéma le laisse entendre. Chaque appareil VPN local est une relation de pair distincte, et la conception multi-appareils de Microsoft donne à chacun sa propre ressource de passerelle de réseau local et sa propre connexion. Ajouter une deuxième adresse à une seule ressource ne crée pas un deuxième pair. Cela crée une ressource qui ne décrit correctement aucun des deux appareils.

Le mythe : une passerelle, deux adresses

Une passerelle de réseau local est la description d’un pair distant : un point de terminaison public et les préfixes privés derrière lui. Aucun moyen pris en charge ne permet à cette ressource de signifier « l’un ou l’autre de ces deux équipements ».

La même confusion existe dans l’autre sens, où deux IP publiques Azure sont lues comme la preuve que deux passerelles Azure existent.

Comptez les objets, puis les tunnels

Prenez deux appareils locaux exploités indépendamment, chacun avec sa propre adresse publique et l’accès aux mêmes réseaux privés, plus une passerelle Azure basée sur le routage en mode actif-actif. La passerelle Azure a deux instances actives avec des IP publiques distinctes. Chaque appareil local se connecte aux deux instances. C’est le maillage complet, et le nombre d’objets en découle, non du schéma.

L’arithmétique est assez courte pour être collée dans le document de conception :

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

Une ressource de connexion peut porter plus d’un tunnel sous-jacent, donc quatre tunnels n’impliquent pas quatre passerelles de réseau virtuel. Deux IP publiques Azure ne sont pas non plus les mêmes objets que les deux passerelles de réseau local qui décrivent le site distant.

Ce que l’actif-actif ajoute côté Azure

L’actif-actif fait passer la passerelle Azure d’une instance active à deux, chacune avec sa propre IP publique, et c’est ce qui rend un maillage complet possible. Il ne double pas le débit d’un seul flux. Il ne supprime pas non plus la nécessité, côté local, de prendre en charge le multipath à coût égal si les deux appareils transmettent en même temps. Confirmez le mode de la passerelle, la référence et les capacités de l’appareil distant avant de provisionner quoi que ce soit.

Une passerelle en veille passive est une conception parfaitement valable ; elle produit simplement un nombre de tunnels différent.

BGP rend les deux chemins utilisables

Pour la conception multi-appareils, les deux appareils locaux exécutent BGP. Donnez à chacun une adresse de pair BGP unique et annoncez les mêmes préfixes privés prévus sur les chemins concernés. Les préfixes privés identifient les réseaux protégés, tandis que les adresses publiques identifient où se terminent les connexions de transport chiffrées. Confondre les deux produit une conception où tous les tunnels sont actifs et les routes incorrectes.

Planifiez le routage de retour et toute inspection avec état qui doit tolérer l’un ou l’autre chemin. Une session IKE saine sur chaque point de terminaison ne prouve pas qu’une charge de travail peut utiliser chaque route annoncée.

La sélection par flux n’est pas une agrégation de bande passante

Azure sélectionne un chemin par flux à l’aide d’un hachage sur l’adressage et les ports du flux. En régime stable, les paquets d’un flux TCP ou UDP donné empruntent normalement le même tunnel, et le côté local peut choisir un autre tunnel pour la direction de retour. Deux appareils et quatre tunnels améliorent donc la disponibilité, pas la vitesse d’un transfert. Quand une présentation commerciale promet de l’agrégation, elle décrit une autre fonctionnalité ou un malentendu.

Testez avec des flux parallèles si vous voulez voir les chemins se répartir, et avec un seul flux si vous voulez voir la limite.

Quelle redondance vous avez réellement supprimée

Deux adresses WAN sur un seul appareil améliorent les options de liaison d’accès tout en partageant l’alimentation, le logiciel et l’état de panne de cet appareil. Elles ne valent pas deux appareils, et aucune configuration côté Azure n’y change rien. Suivez la conception double WAN ou en cluster prise en charge par le fournisseur au lieu de déduire la redondance du nombre d’adresses. Testez ensuite : retirez un chemin à la fois et confirmez les routes restantes ainsi qu’un échange applicatif réel dans les deux sens.

Attendez-vous à des délais de détection et de convergence, et à ce que certaines sessions existantes se terminent.