Les stratégies de connexion entre des réseaux Cloud et/ou sur site sont déjà possibles grâce aux appairages, aux passerelles VPN et encore bien d’autres. Mais force est de constater qu’Azure WAN simplifie la mise en œuvre d’une architecture multi-réseaux. Et bien figurez-vous que j’ai justement pu enfin trouver le temps pour le tester cet Azure WAN ! 😎
Avant vous parler du test que j’ai réalisé sur ce service, commençons d’abord par quelques notions sur Azure WAN.
Qu’est-ce qu’Azure WAN ?
Azure WAN facilite la connexion des sites distants, des succursales ou des utilisateurs via un réseau centralisé. Cela permet d’intégrer plusieurs réseaux locaux (LAN) sur un WAN global, améliorant ainsi la connectivité et la gestion.
Azure WAN est un concentré de services réseaux déjà disponibles sur le Cloud Microsoft. Il propose de mettre en place et de gérer de façon simple et rapide différents types de liaison dans le Cloud et/ou sur site.
Mais seulement cette simplicité n’est pas un synonyme d’économie : Azure WAN propose dès les premiers liens des puissances assez grandes. Et qui dit performances, dit coûts.
Azure Virtual WAN est un service de mise en réseau qui combine un grand nombre de fonctionnalités de mise en réseau, de sécurité et de routage pour fournir une interface opérationnelle unique.
Voici quelques-unes des fonctionnalités principales :
- Connectivité de branche (via l’automatisation de la connectivité à partir d’appareils partenaires Virtual WAN, comme SD-WAN ou CPE VPN).
- Connectivité VPN de site à site.
- Connectivité VPN d’un utilisateur distant (point à site).
- Connectivité privée (ExpressRoute).
- Connectivité multicloud (connectivité transitive pour les réseaux virtuels).
- Interconnectivité ExpressRoute des VPN.
- Routage, Pare-feu Azure et chiffrement pour la connectivité privée.
Grâce à son interface unique et centralisée, les administrateurs réseau peuvent configurer et surveiller facilement l’ensemble du réseau WAN, incluant les connexions des utilisateurs, les VPN, et les passerelles virtuelles. Cela simplifie donc l’administration des réseaux complexes.
Dans quel cas considérer Azure WAN ?
Le service est idéal pour les environnements hybrides ou multicloud, en offrant une connectivité fluide entre les réseaux sur site et divers fournisseurs de cloud.
Azure WAN est avant tout une boîte à outils où les liaisons entre ressources Azure et/ou sur sites sont vraiment très simples à mettre en œuvre.
Quels SKUs sont disponibles pour Azure WAN ?
Azure WAN permet de réduire les coûts en diminuant la nécessité d’équipements réseau sur site. L’approche as-a-service signifie que les entreprises paient uniquement pour ce qu’elles utilisent, réduisant ainsi les coûts d’infrastructure.
A ce jour, 2 SKUs sont déjà disponibles pour Azure WAN. Microsoft nous expose via le tableau ci-dessous les différences :
| Type de Virtual WAN | Type de Hub | Configurations disponibles |
|---|---|---|
| De base | De base | VPN de site à site uniquement |
| standard | standard | ExpressRoute VPN utilisateur (point à site) VPN (site à site) Transit de hub à hub et de réseau virtuel à réseau virtuel via le hub virtuel Pare-feu Azure NVA est un WAN virtuel |
Autrement dit, l’Azure WAN de base, bien que gratuit (base + traffic), apportera seulement les connexions VPN site à site et aux réseaux virtuels Azure, mais certaines liaisons sont manquantes comme :
- Connexion entre les hubs
- Connectivité ExpressRoute
- Connectivité VPN utilisateur/point à site
- Connectivité de réseau virtuel à réseau virtuel Azure
- Azure Firewall
Enfin, Il est malgré tout possible de migrer depuis le SKU Basic vers Standard, mais pas l’inverse :
Quels sont les autres coûts liés au services Azure WAN ?
La tarification du service Azure WAN est très fragmenté. La facturation dépendra des différents trafics réseaux, et donc se divisera potentiellement en une myriade de petits frais.
Dans l’image ci-dessous, pas loin de 13 différents types de transfert sont facturés par Microsoft :
Pour y voir plus clair sur le trafic réseaux d’Azure WAN, Microsoft propose différents scénarios concrets disponibles juste là.
Tarification de la liaison :
Microsoft communique également via leur site web le détail tarifaire complet des liaisons réseaux possibles :
Tarification de la données en transit :
Microsoft nous rappelle ici les différents prix au Go de données transférées entre des réseaux sur Azure et/ou sur site :
Afin de comprendre comment déployer Azure WAN, j’ai décidé de recréer une petite infrastructure réseau, répartie sur plusieurs régions Azure :
Par manque de temps et de connaissances, je n’ai pas testé Firewall et la fonctionnalité BGP sur mon test d’Azure WAN.
Mon test d’Azure WAN :
Mon environnement WAN de test est constitué des éléments Azure suivants :
- 1 Azure WAN avec 2 Azure Hub :
- 4 réseaux virtuels Azure contenant chacun une machine virtuelle :
- 2 VPN Gateway Site à Site :
- 2 VPN Gateway Point à Site avec une configuration P2S VPN globale WAN :
J’ai recréé sur Azure différentes ressources pour simuler deux environnements sur site :
- 2 réseaux en connexion site à site avec 2 passerelles VPN :
- 2 réseaux en connexion point à site avec des PCs équipés du client Azure VPN :
Afin d’effectuer mes tests de connectivités entre tous ces réseaux, j’ai également déployé les machines virtuelles suivantes :
Afin d’avoir une vue d’ensemble de l’infrastructure WAN, Microsoft propose une cartographie fidèle avec toutes les liaisons internes et externes :
Toute la configuration WAN côté infrastructure Azure peut s’effectuer directement depuis la page du portail Azure dédiée à mon Azure WAN.
Configuration WAN :
Pour arriver à ce résultat, une fois le WAN déployé, j’ai créé ici les 2 hubs suivants :
J’ai activé les liaisons suivantes via la configuration de mon WAN :
Configuration des 2 hubs :
Pour chacun des 2 hubs, j’ai activé les passerelles VPN Site à Site et Point à Site (30 minutes d’attente par liaison) :
Connexions aux 4 réseaux virtuels Azure :
Depuis la page d’Azure WAN, j’ai connecté les 4 réseaux virtuels internes à mon infrastructure Azure à mes 2 hubs :
J’ai utilisé la route par Default pour chacune des liaisons :
Connexions aux réseaux locaux Site à site :
Depuis la page Azure WAN, j’ai créé 2 sites physiques respectivement connectés à mes 2 hubs :
Pour chacun des 2 sites, j’ai indiqué leur plan d’adressage respectif :
Une fois les 2 liaisons VPN Site à Site déployées et connectées, ces dernières sont alors bien respectivement visibles sur les 2 hubs :
Une fois toutes les connexions internes et externes en place, les différentes routes sont bien visibles sur chacun de mes 2 hubs :
Connexions Points à site :
Toujours sur la page Azure WAN, j’ai mis en place une configuration unique concernant le type de tunnel et la méthode d’authentification Entra ID :
Afin d’assurer une authentification via Entra ID, j’ai mis en place un tunnel Point à Site de type OpenVPN :
Comme mon précédent article parlant déjà du VPN Point à Site, j’ai configuré les informations suivantes en relation avec mon tenant Microsoft :
J’ai installé Azure VPN sur mes 2 PCs situés en mobilité :
La configuration VPN établie par mon WAN repose sur un FQDN unique. Cela permet d’établir la connexion Point à Site vers le hub le plus proche de façon transparente et automatique :
Poste 1 :
Poste 2 :
Une fois la connexion VPN cliente établie, les informations sont visibles sur le hub :
Mon environnement WAN est maintenant en place, il ne me reste plus qu’à tester les accès et la transitivité de l’infrastructure toute entière.
Tests des accès :
Pour cela, j’ai installé le service Azure Bastion sur le réseau virtuel contenant un PC en mobilité :
J’ai démarré la connexion Point à Site via Azure VPN en utilisant le SSO de l’OS :
J’ai pu ouvrir avec succès des connexions RDP vers toutes les machines virtuelles de mon WAN :
- Second PC en mobilité ayant une connexion Point à Site ouverte sur l’autre hub
- Serveur ayant une connexion Site à Site ouverte sur le même hub
- Serveur ayant une connexion Site à Site ouverte sur l’autre hub
- Serveurs ayant un appairage de réseau virtuel sur le même hub
- Serveurs ayant un appairage de réseau virtuel sur l’autre hub
Le routage vers toutes les machines s’est donc effectuée sans aucun autre composant additionnel qu’Azure WAN lui-même 💪
Surveillance des liaisons :
Une fois le WAN en place, la surveillance des liaisons est indispensable afin d’y remédier au plus vite car ces dernières sont souvent critiques pour un ou plusieurs services de l’entreprise.
Pour cela des métriques sont disponibles via le menu Insights de mon Azure WAN :
De plus, Azure WAN peut s’appuyer sur le service Connection Monitor disponible sous Network Watcher afin d’établir des tests de connectivité et des règles d’alerte.
J’ai configuré Connection Monitor afin d’effectuer des tests ICMP vers Azure, mais aussi vers mes 2 sites physiques :
A peine les tests créés, Connection Monitor affiche les résultats :
Différentes informations sont disponibles sur ces tests :
Afin de simuler une panne, j’ai simplement éteint une machine virtuelle Azure sur site :
A peinte la machine virtuelle éteinte, Connection Monitor indique déjà des échecs dans les tests concernés :
Le détail du test en défaut nous affiche également le routage et même le lieu exact du blocage de la liaison :
Azure Monitor affiche également les 2 alerte déclenchée :
Grâce au groupe d’action configuré sur la règle de l’alerte créée par Connection Monitor, une notification par e-mail me parvient immédiatement :
Afin de retrouver une situation opérationnelle, je rallume la machine virtuelle sur site précédemment éteinte :
Quelques minutes plus tard, les alertes générées sont automatiquement résolues :
De retour sur Connection Monitor, tous les tests repassent alors en vert :
Conclusion
En résumé, Azure WAN offre une solution robuste, sécurisée et évolutive pour connecter et gérer les réseaux distribués à travers le monde. Il simplifie la gestion des infrastructures réseau tout en garantissant des performances et une sécurité optimales, ce qui en fait une option précieuse pour les entreprises cherchant à moderniser leurs infrastructures réseau.
