Microsoft AZ-700: Réseau hybride — Guide d'étude

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Network Engineer AZ-700 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Principes fondamentaux de la connectivité hybride et contraintes d’adressage

La connectivité hybride consiste à établir une joignabilité IP fiable, routable et sécurisée entre les réseaux locaux (on-premises) et les réseaux virtuels Azure. Lors de la planification de l’adressage du réseau virtuel, n’oubliez pas que certaines ressources gérées par Azure au sein d’un sous-réseau nécessitent une allocation d’adresses contiguës et sans conflit, et parfois des adresses réservées spécifiques : les équilibreurs de charge Azure (load balancers) et les sous-réseaux de passerelle doivent être découpés intentionnellement (le GatewaySubnet doit être nommé exactement ainsi et dimensionné pour s’adapter à la mise à l’échelle du SKU de la passerelle), et les points de terminaison privés ainsi que les points de terminaison de service gérés par Azure nécessitent des adresses prélevées sur le VNet qui les héberge. Le chevauchement des préfixes on-prem et Azure est le piège le plus courant : des plages qui se chevauchent cassent le routage et la sélection de route BGP, créent un routage asymétrique et compliquent les politiques de pare-feu. Utilisez des segments d’au moins /27 à /24 pour les sous-réseaux hébergeant des pare-feu avec état (stateful), des équilibreurs de charge ou de nombreux points de terminaison privés ; réservez un GatewaySubnet dédié (/27 ou plus grand selon le SKU). Le DNS est tout aussi essentiel : les points de terminaison privés utilisent des zones DNS privées de la plateforme (par exemple, privatelink.database.windows.net), de sorte que des redirecteurs conditionnels (conditional forwarders) ou Azure DNS Private Resolver sont nécessaires on-prem pour résoudre les noms privés Azure. Les compromis de conception s’articulent autour de l’utilisation des adresses IP par rapport à la résilience : des schémas IPv4 plus denses économisent de l’espace d’adressage mais augmentent le risque de collision et de migration, tandis que des préfixes plus grands et moins efficaces simplifient l’expansion future et les stratégies d’annonce BGP.

SKU de VPN Gateway, principes fondamentaux de BGP et passerelles de réseau local

Le choix du bon SKU de passerelle VPN (VpnGw1–VpnGw5, Basic pour les versions héritées) affecte directement le débit, le nombre de sessions S2S/P2S simultanées et les fonctionnalités disponibles comme le mode actif-actif ou les limites de routes. Utilisez des passerelles basées sur le routage (route-based) pour les conceptions hybrides modernes ; l’approche basée sur des stratégies (policy-based) est héritée et limite l’utilisation de BGP. BGP permet l’échange dynamique de préfixes et prend en charge la résilience des chemins, le basculement automatique et la priorisation des préfixes — configurez l’ASN de l’Azure VPN Gateway (65515 par défaut) et faites-le correspondre ou appariez-le avec l’ASN on-prem dans l’objet Local Network Gateway. La passerelle de réseau local (Local Network Gateway) stocke l’adresse IP publique on-prem, l’espace ou les espaces d’adressage, ainsi que l’IP et l’ASN du pair BGP (optionnels) ; oublier de renseigner l’IP du pair BGP ou avoir des ASN qui ne correspondent pas empêche la propagation des routes et conduit à des contournements par routes statiques. Envisagez les hubs Azure Virtual WAN pour une mise à l’échelle multi-sites et un routage de transit intégré ; les hubs VWAN prennent en charge le S2S et le P2S à grande échelle et s’intègrent avec Azure Firewall et ExpressRoute. Faites attention à la propagation de la table de routage : par défaut, certaines topologies hub-and-spoke ou avec appliance virtuelle suppriment la propagation automatique ; des UDR explicites ou des annonces de routes BGP peuvent être nécessaires. Compromis : des SKU plus élevés et VWAN augmentent le coût mais réduisent la charge de gestion (overhead) et améliorent le débit ainsi que la mise à l’échelle du routage.

Choix de conception Point-to-Site, prise en charge des clients et intégration DNS

Les choix pour le Point-to-Site (P2S) déterminent la compatibilité des clients, l’authentification et la mise à l’échelle. OpenVPN (SSL) est le plus multiplateforme et est recommandé pour les clients macOS, Linux et mobiles ; IKEv2 est léger et fonctionne bien avec les clients natifs de macOS ; SSTP reste une option pour les scénarios plus anciens uniquement sous Windows. Les modes d’authentification incluent Azure Active Directory (recommandé pour l’intégration des identités et l’accès conditionnel), l’authentification par certificat, et RADIUS pour les solutions MFA on-premises ou basées sur RADIUS. Le SKU de la passerelle VPN dicte le nombre de tunnels P2S et le débit ; choisissez VpnGw2/3 pour des pools d’utilisateurs de taille moyenne à grande et VpnGw4/5 pour une mise à l’échelle importante ou une utilisation sensible au débit. Les points de terminaison privés et le P2S interagissent via le DNS : pour permettre aux clients P2S de résoudre les noms des points de terminaison privés (zones privatelink), il faut soit lier les zones DNS privées au VNet, soit utiliser Azure DNS Private Resolver et des redirecteurs conditionnels depuis le DNS on-prem ou celui du client. Un piège fréquent est d’oublier que les clients P2S n’utilisent normalement le DNS Azure fourni par la passerelle que lorsque le client propage (push) les routes et les paramètres DNS ; des configurations explicites de suffixe DNS et de redirecteur évitent les problèmes de type « impossible de résoudre le point de terminaison privé ». Équilibrez l’évolutivité et le coût : l’authentification par certificat est peu coûteuse mais plus difficile à révoquer ; Azure AD offre des contrôles de sécurité modernes mais ajoute des coûts de licence et de la complexité.

Routage de transit, tunneling forcé, inspection et placement des appliances de sécurité

La conception du transit entre plusieurs VNets, l’environnement sur site et les appliances d’inspection nécessite une application claire des frontières de routage et de NAT. Forcer le trafic à travers Azure Firewall ou des appliances virtuelles requiert des routes définies par l’utilisateur (UDR) pointant vers l’adresse IP privée du pare-feu ou l’utilisation du routage de hub Virtual WAN pour centraliser l’inspection. Si vous avez besoin d’un proxy totalement transparent ou d’une inspection TLS, placez l’appliance dans un sous-réseau d’inspection dédié et assurez-vous que les SKU du sous-réseau de la passerelle et du pare-feu prennent en charge le transit pour le débit attendu. Portez une attention particulière au comportement SNAT et aux choix des SKU d’adresses IP publiques : les adresses IP publiques Standard et la passerelle NAT sont recommandées pour un SNAT sortant prévisible et des règles de sécurité ; la passerelle NAT associée à un ensemble d’adresses IP publiques Standard décharge le SNAT et évite la prolifération d’adresses IP publiques par machine virtuelle. Un piège courant est le routage asymétrique lorsque les routes sur site et les UDR Azure font en sorte que le trafic de retour contourne l’appliance prévue ; assurez-vous que tous les spokes annoncent les préfixes requis via BGP ou disposent d’UDR qui dirigent le trafic vers le point d’inspection. Performance vs coût : une architecture hub-and-spoke avec Azure Firewall Premium ou des appliances tierces à haut débit augmente la protection et la gestion centralisée, mais augmente également les coûts et le risque de défaillance d’un hub unique, à moins de déployer des hubs redondants actif-actif et d’associer des passerelles entre les régions.

Problème pratique : Scénario d’utilisation

Scénario : Contoso Ltd possède deux datacenters sur site (Seattle et Amsterdam) et un environnement Azure existant avec trois VNets (VNet-Prod, VNet-Shared, VNet-Dev) dans un unique VNet hub (VNet-Hub). Ils utilisent actuellement une passerelle VPN VpnGw1 pour Seattle et une connexion site-to-site vers un hub Azure Virtual WAN pour Amsterdam. Des points de terminaison privés sont utilisés pour Azure SQL dans VNet-Shared.

Défi : Contoso a besoin d’une connectivité hybride résiliente et évolutive avec un routage dynamique (BGP) entre les deux datacenters et Azure, d’une prise en charge P2S fiable pour les utilisateurs macOS, de la résolution DNS des points de terminaison privés depuis l’environnement sur site, et d’une inspection centralisée du trafic sortant des spokes via Azure Firewall.

Approche recommandée :

1. Déployer une nouvelle passerelle VPN VpnGw3 basée sur les routes dans VNet-Hub, configurée en mode actif-actif avec BGP activé (définir explicitement l’ASN de la passerelle) et mettre à jour les objets de passerelle de réseau local avec les adresses IP des pairs BGP et les ASN sur site ; migrer la connexion S2S de Seattle vers la nouvelle passerelle pour prendre en charge un débit et des limites de routes plus élevés.
2. Consolider la connexion d’Amsterdam dans le hub en établissant une connexion ExpressRoute ou en migrant le hub VWAN vers un peering de hub avec VNet-Hub ; assurer l’échange de routes BGP entre les deux datacenters pour éviter les routes statiques et permettre un basculement automatique.
3. Configurer le P2S en utilisant le protocole OpenVPN avec l’authentification Azure AD sur la VpnGw3 pour prendre en charge les clients macOS (IKEv2 en solution de secours), et dimensionner les pools de clients selon les limites de la VpnGw3 ; publier un redirecteur conditionnel sur le DNS sur site pour rediriger les zones privatelink.* vers un Azure DNS Private Resolver déployé dans VNet-Shared et lié aux zones DNS privées pour les points de terminaison privés.
4. Déployer Azure Firewall (Standard ou Premium si l’inspection TLS est requise) dans VNet-Hub en configuration actif-actif et créer des UDR pour les sous-réseaux des spokes qui dirigent 0.0.0.0/0 vers l’adresse IP privée du pare-feu ; attacher une passerelle NAT avec des adresses IP publiques Standard au pare-feu ou utiliser l’adresse IP publique du pare-feu pour un SNAT explicite et une journalisation vers un espace de travail Log Analytics central.

Justification : L’utilisation de VpnGw3 avec BGP fournit une propagation dynamique des routes et un débit suffisant pour une résilience multi-sites ; OpenVPN + Azure AD prend en charge les utilisateurs macOS de manière sécurisée ; la redirection DNS vers Azure DNS Private Resolver assure la résolution des noms des points de terminaison privés depuis l’environnement sur site ; la centralisation de l’inspection dans un hub Azure Firewall avec des UDR évite le routage asymétrique et simplifie la gestion des politiques, en échangeant un coût plus élevé contre une sécurité et une observabilité centralisées.

← Conception d’Azure Virtual Network · Tous les domaines · Azure DNS et résolution de noms →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →