Empêcher l’épuisement IPv4 dans Azure

Cet article explique comment réduire la consommation d’espace d’adressage privé lorsque vous créez de grands réseaux dans Azure. Vous devrez peut-être réduire la consommation d’espace d’adressage si des stratégies d’allocation appropriées ne sont pas établies et que vous ne disposez pas d’adresses IP privées à attribuer à des réseaux virtuels Azure. Cet article présente deux méthodes pour gérer de manière appropriée des adresses IP dans Azure.

Détails du scénario

Les réseaux d’entreprise utilisent généralement des espaces d’adressage qui se trouvent dans les plages d’adresses IPv4 privées définies dans la RFC 1918. Les plages d’adresses sont 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. Dans les environnements locaux, ces plages fournissent suffisamment d’adresses IP pour répondre aux exigences des plus grands réseaux. Par conséquent, de nombreuses organisations développent des pratiques de gestion des adresses qui classent par ordre de priorité les configurations de routage simples et les processus agiles pour l’allocation d’adresses IP. L’utilisation efficace de l’espace d’adressage n’est pas une priorité.

Dans le cloud, les grands réseaux hybrides sont faciles à créer, et certains modèles architecturaux courants, tels que les microservices ou la conteneurisation, peuvent entraîner une augmentation de la consommation d’adresses IP. Il est donc important d’ajuster ces pratiques de gestion des adresses. Dans un environnement cloud, considérez les adresses IPv4 privées comme une ressource limitée.

Plages d’adresses IP du réseau virtuel Azure

Dans vos réseaux virtuels Azure, nous vous recommandons d’utiliser les blocs d’adresses définis par la RFC 1918. Ces blocs d’adresses sont destinés aux réseaux privés à usage général et ne peuvent pas être routés sur l’Internet public.

Vous pouvez utiliser d’autres plages, mais avant d’utiliser ces plages dans votre réseau virtuel, lisez la documentation IANA (Internet Assigned Numbers Authority) pour comprendre les implications potentielles pour votre environnement. Vous pouvez utiliser les plages suivantes :

• Espace d’adressage partagé défini par la RFC 6598 pour la traduction d’adresses réseau (NAT) de niveau opérateur, qui est considéré comme un espace d’adressage privé dans le réseau virtuel Azure. Le bloc d’adresses est 100.64.0.0/10.
• Adresses IP publiques routables sur Internet qui n’appartiennent pas à votre organisation. Cette pratique est déconseillée, car les ressources du réseau virtuel ne peuvent pas accéder aux points de terminaison Internet qui sont exposés sur les adresses IP publiques.
• Blocs d’adresses à usage spécial définis par IANA, comme 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, et 233.252.0.0/24.

Vous ne pouvez pas utiliser les plages d’adresses IP suivantes dans les réseaux virtuels Azure :

• 224.0.0.0/4 (multidiffusion)
• 255.255.255.255/32 (diffusion)
• 127.0.0.0/8 (bouclage)
• 169.254.0.0/16 (lien-local)
• 168.63.129.16/32 (DNS interne)

Alignement de la zone d’atterrissage Azure

Les recommandations de cet article concernent les scénarios basés sur l’architecture de zone d’atterrissage Azure. L’aide part du principe que :

• Chaque région dispose d’une topologie hub-and-spoke.
• Les réseaux hub-and-spoke situés dans des régions différentes sont connectés les uns aux autres par le biais d’un appairage de réseaux virtuels global ou de connexions au même ou à plusieurs circuits Azure ExpressRoute.
• Les réseaux hub-and-spoke sont connectés à des sites locaux via une combinaison de circuits ExpressRoute et de VPN site à site.

Le diagramme suivant illustre un exemple d’architecture. Les recommandations s’appliquent également aux réseaux sur Azure Virtual WAN, qui dispose également de réseaux hub-and-spoke dans chaque région.

Téléchargez un fichier PowerPoint de cette architecture.

Dans un scénario basé sur l’architecture de zone d’atterrissage Azure, les applications sont déployées dans leur propre zone d’atterrissage. Chaque zone d’atterrissage contient un réseau virtuel spoke appairé à un hub régional. Les réseaux virtuels spoke font partie intégrante du réseau d’entreprise et se voient attribuer des adresses IPv4 routables. Ces adresses sont uniques sur l’ensemble du réseau d’entreprise. Tous les composants architecturaux déployés dans le réseau virtuel Azure consomment donc des adresses IPv4 dans l’espace d’adressage du réseau d’entreprise, même si seuls quelques composants exposent des points de terminaison qui doivent être accessibles à partir de l’ensemble du réseau d’entreprise. Ces composants architecturaux peuvent être des machines virtuelles, des appliances virtuelles réseau internes ou tierces, ou des services PaaS (Platform-as-a-Service) injectés dans le réseau virtuel.

Pour le reste de cet article, le composant front-end fait référence à un composant d’application accessible à partir de l’ensemble du réseau d’entreprise ou de l’extérieur de la zone d’atterrissage du composant. Le composant back-end fait référence à un composant d’application qui n’expose pas de points de terminaison dans le réseau d’entreprise et qui ne doit être accessible qu’à partir de sa propre zone d’atterrissage. Par exemple, une application web qui expose un point de terminaison est un composant front-end, et une base de données qui n’expose pas de point de terminaison est un composant back-end.

Les sections suivantes décrivent deux méthodes pour réduire la consommation d’espace d’adressage privé lorsque vous créez de grands réseaux dans Azure.

Méthode 1 : Réseaux virtuels spoke de zone d’atterrissage non routables

La RFC 1918 extrait les blocs d’adresses IP de l’espace d’adressage IPv4 32 bits et les rend non routables sur l’Internet public, de sorte que vous pouvez les réutiliser dans plusieurs réseaux privés pour la communication interne. Cette méthode est basée sur le même principe que celui qui s’applique à l’espace d’adressage privé. Une ou plusieurs plages d’adresses sont découpées dans l’ensemble de l’espace d’adressage privé utilisé par votre organisation et déclarées non routables dans le réseau d’entreprise de votre organisation. Les plages d’adresses sont réutilisées dans plusieurs zones d’atterrissage. Par conséquent, pour chaque zone d’atterrissage :

• Un espace d’adressage routable composé d’une ou plusieurs plages d’adresses est attribué. Votre organisation gère de manière centralisée les plages d’adresses et les attribue de manière unique à une zone d’atterrissage pour communiquer avec le réseau d’entreprise. Les adresses dans l’espace routable sont attribuées aux composants front-end.
• L’espace d’adressage non routable, qui correspond aux plages d’adresses que votre organisation déclare non routables dans le réseau d’entreprise, peut être utilisé. Vous pouvez utiliser ces plages réservées pour la communication interne dans toutes les zones d’atterrissage. Les adresses dans l’espace non routable sont attribuées aux composants back-end.

Dans un réseau hub-and-spoke Azure géré par le client ou basé sur Virtual WAN, deux réseaux virtuels spoke ou plus ne peuvent pas avoir d’espaces d’adressage IP qui se chevauchent. Les blocs d’adresses non routables ne peuvent pas être attribués à un spoke de zone d’atterrissage. L’appairage de réseaux virtuels n’étant pas transitif, un réseau virtuel spoke de zone d’atterrissage peut s’appairer avec un réseau virtuel spoke de deuxième niveau qui a un espace d’adressage non routable. Le diagramme suivant illustre la topologie de réseau virtuel double pour les zones d’atterrissage.

Téléchargez un fichier PowerPoint de cette architecture.

Chaque zone d’atterrissage d’application contient deux réseaux virtuels appairés. Un réseau virtuel possède des adresses IP routables et héberge des composants front-end. L’autre réseau virtuel possède des adresses IP non routables et héberge des composants back-end. Le spoke de zone d’atterrissage routable est appairé au hub régional. Le spoke de zone d’atterrissage non routable est appairé avec le spoke de zone d’atterrissage routable. L’appairage de réseaux virtuels n’étant pas transitif, les préfixes non routables ne sont pas visibles pour le hub régional ou le reste du réseau d’entreprise. Les réseaux virtuels routables ne peuvent pas utiliser les plages d’adresses non routables. Certaines organisations disposent d’un espace d’adressage fragmenté qui est déjà attribué à des réseaux routables. Il peut être difficile d’identifier les grands blocs d’adresses inutilisés et de les déclarer non routables. Dans ce cas, considérez les adresses inutilisées qui ne sont pas incluses dans l’espace d’adressage RFC 1918. Le diagramme précédent fournit un exemple d’adresses NAT de niveau opérateur, comme RFC 6598, dans des réseaux virtuels spoke non routables.

Migration d’une zone d’atterrissage de réseau virtuel unique

L’appairage de réseaux virtuels fournit une connectivité de couche 3 complète entre deux réseaux virtuels appairés. Les composants d’application déployés dans des zones d’atterrissage de réseau virtuel unique traditionnelles qui communiquent entre eux via des adresses IP peuvent être déplacés librement entre des réseaux virtuels spoke routables et non routables dans une zone d’atterrissage. Cette section décrit deux modèles de migration classiques.

Les applications suivantes sont exposées par le biais de contrôleurs de remise d’applications de couche 7 :

Téléchargez un fichier PowerPoint de cette architecture.

Les applications exposées par le biais de contrôleurs de remise d’applications de couche 7 peuvent être déplacées vers le spoke non routable. Le contrôleur de remise d’applications est le seul composant front-end qui doit résider dans le spoke de zone d’atterrissage routable.

Les applications suivantes sont exposées via un équilibreur de charge Azure :

Téléchargez un fichier PowerPoint de cette architecture.

Si une application expose ses points de terminaison via un équilibreur de charge Azure, les instances de calcul qui font partie du pool back-end de l’équilibreur de charge doivent rester dans le même réseau virtuel. Les équilibreurs de charge Azure prennent uniquement en charge les instances back-end dans leur propre réseau virtuel.

Dépendances sortantes

Les composants back-end d’une application n’ont pas besoin d’être accessibles ou de recevoir des connexions entrantes depuis le réseau d’entreprise, mais ils disposent souvent de dépendances sortantes. Les composants back-end peuvent avoir besoin de se connecter à des points de terminaison qui se trouvent en dehors de leurs zones d'atterrissage dans des cas tels que la résolution DNS, les contrôleurs de domaine des services Active Directory, l'accès à des points de terminaison d'application qui sont exposés par d'autres zones d'atterrissage, ou l'accès à des installations de journalisation ou de sauvegarde.

Lorsque les services initient des connexions dans des réseaux virtuels spoke non routables, vous devez implémenter la NAT source (SNAT) pour les connexions derrière une adresse IP routable. Pour implémenter SNAT, déployez un appareil compatible avec NAT dans le réseau virtuel spoke routable. Chaque zone d’atterrissage exécute sa propre appliance virtuelle réseau de NAT dédiée. Il existe deux options pour implémenter SNAT dans une zone d’atterrissage : le Pare-feu Azure ou des appliances virtuelles réseau tierces. Dans les deux cas, tous les sous-réseaux du spoke non routable doivent être associés à une table de routage personnalisée. Comme illustré dans le diagramme suivant, la table de routage transfère le trafic vers des destinations en dehors de la zone d’atterrissage vers l’appareil SNAT. Azure NAT Gateway ne prend pas en charge SNAT pour le trafic destiné à l’espace d’adressage IP privé, tel que l’espace RFC 1918.

Téléchargez un fichier PowerPoint de cette architecture.

Implémenter SNAT via le Pare-feu Azure

Pare-feu Azure :

• Fournit une haute disponibilité.
• Fournit une scalabilité native et trois références SKU différentes. SNAT n’étant pas une tâche qui consomme beaucoup de ressources, concentrez-vous d’abord sur la référence SKU de base. Pour les zones d’atterrissage qui nécessitent de gros volumes de trafic sortant à partir de l’espace d’adressage non routable, utilisez la référence SKU standard.
• Effectue la traduction SNAT pour le trafic derrière les adresses IP privées de l’une de ses instances. Chaque instance peut utiliser tous les ports non privilégiés.

Le diagramme suivant illustre la disposition de la zone d’atterrissage pour implémenter SNAT dans une topologie de réseau hub-and-spoke à l’aide du Pare-feu Azure.

Téléchargez un fichier PowerPoint de cette architecture.

Vous devez associer tous les sous-réseaux du spoke non routable à une table de routage personnalisée pour envoyer le trafic vers des destinations en dehors de la zone d’atterrissage vers le Pare-feu Azure.

Le diagramme suivant illustre la disposition de la zone d’atterrissage pour implémenter SNAT dans un réseau hub-and-spoke basé sur Virtual WAN à l’aide du Pare-feu Azure.

Téléchargez un fichier PowerPoint de cette architecture.

Vous devez associer tous les sous-réseaux du spoke non routable, ou les spokes qui ne sont pas connectés à Virtual WAN, à une table de routage personnalisée pour envoyer le trafic vers des destinations en dehors de la zone d’atterrissage vers le Pare-feu Azure.

Pour les deux dispositions, pour fournir aux ressources du spoke non routable un accès aux adresses IP routables en dehors de leur zone d’atterrissage, vous devez déployer le Pare-feu Azure avec l’option Effectuer une traduction SNAT définie sur Toujours dans le spoke routable de chaque zone d’atterrissage. Vous trouverez des instructions sur la configuration du Pare-feu Azure pour implémenter SNAT sur toutes les connexions reçues dans la documentation publique. La capture d’écran suivante montre la configuration requise pour utiliser le Pare-feu Azure en tant qu’appareil NAT pour les connexions initiées par des ressources dans des réseaux virtuels spoke non routables.

Implémenter SNAT via des appliances virtuelles réseau tierces

Les appliances virtuelles réseau tierces avec des fonctionnalités NAT sont disponibles sur la Place de marché Azure. Elles fournissent :

• Contrôle granulaire du scale-in et du scale-out.
• Contrôle granulaire du pool NAT.
• Stratégies NAT personnalisées, telles que l’utilisation de différentes adresses NAT en fonction des propriétés de la connexion entrante, comme l’adresse IP source ou de destination.

Tenez compte des recommandations suivantes :

• Pour la haute disponibilité, déployez des clusters avec au moins deux appliances virtuelles réseau. Utilisez un équilibreur de charge Azure pour distribuer les connexions entrantes du réseau virtuel spoke non routable aux appliances virtuelles réseau. Une règle d’équilibrage de charge des ports à haute disponibilité est requise, car le cluster implémente SNAT sur toutes les connexions qui quittent la zone d’atterrissage. Azure Standard Load Balancer prend en charge les règles d’équilibrage de charge des ports à haute disponibilité.
• La pile Azure SDN prend en charge les appliances virtuelles réseau à un et deux bras. Les appliances virtuelles réseau à un bras sont préférées, car elles réduisent la consommation d’espace d’adressage dans les réseaux virtuels spoke routables.

Le diagramme suivant illustre la disposition de la zone d’atterrissage pour implémenter SNAT dans une topologie de réseau hub-and-spoke à l’aide d’appliances virtuelles réseau tierces.

Téléchargez un fichier PowerPoint de cette architecture.

Le diagramme suivant illustre la disposition de la zone d’atterrissage pour implémenter SNAT dans une topologie de réseau hub-and-spoke basée sur Virtual WAN à l’aide d’appliances virtuelles réseau tierces.

Téléchargez un fichier PowerPoint de cette architecture.

Pour les deux dispositions d’appliances virtuelles réseau tierces, vous devez déployer plusieurs instances derrière un équilibreur de charge Azure pour fournir une haute disponibilité. La référence SKU standard d’Azure Load Balancer est requise.

Méthode 2 : Services Azure Private Link

Azure Private Link permet d’accéder aux applications déployées dans un réseau virtuel qui n’est pas connecté à votre réseau virtuel. Dans le réseau virtuel côté serveur ou application, un service Private Link est déployé et associé à un point de terminaison d’application qui est exposé sur l’adresse IP front-end d’un équilibreur de charge de référence SKU standard Azure interne. Dans le réseau virtuel côté client, une ressource de point de terminaison privé est déployée et associée au service Private Link. Le point de terminaison privé expose le point de terminaison d’application dans vos réseaux virtuels. Private Link fournit le tunneling et la logique NAT pour réaliser le routage du trafic entre le côté client et le côté serveur. Pour plus d’informations, consultez Qu’est-ce qu’Azure Private Link ?

Private Link ne nécessite pas de connexion de couche 3 entre le réseau virtuel côté client et le réseau virtuel côté serveur. Les deux réseaux virtuels peuvent avoir des espaces d’adressage IP qui se chevauchent. Private Link permet le déploiement d’applications dans des réseaux virtuels dédiés et isolés, tous utilisant le même espace d’adressage non routable. Les applications sont exposées en tant que services Private Link dans le réseau d’entreprise, qui utilise un espace d’adressage routable. Dans le contexte de l’architecture de la zone d’atterrissage Azure, la topologie de zone d’atterrissage résultante a :

• Un réseau virtuel isolé qui héberge l’ensemble de l’application et le service Private Link associé aux points de terminaison de l’application. L’équipe d’application définit l’espace d’adressage du réseau virtuel.
• Un réseau virtuel spoke avec un espace d’adressage routable qui héberge le point de terminaison privé associé au service Private Link. Le réseau virtuel spoke est directement appairé au hub régional.

Le diagramme suivant illustre la topologie de zone d’atterrissage avec Private Link.

Téléchargez un fichier PowerPoint de cette architecture.

Utiliser un service Private Link pour les dépendances sortantes

Lorsque vous déployez des applications dans des réseaux virtuels spoke isolés, utilisez un service Private Link pour les dépendances sortantes. Définissez des points de terminaison privés dans le réseau virtuel spoke isolé et associez-les à un service Private Link dans des réseaux virtuels routables. Le diagramme suivant illustre l’approche conceptuelle.

Téléchargez un fichier PowerPoint de cette architecture.

Dans les implémentations réelles à grande échelle, la méthode Private Link peut ne pas s’appliquer :

• Si les applications déployées dans le réseau virtuel isolé possèdent plusieurs dépendances sortantes. Quand vous déployez un service Private Link et un point de terminaison privé pour chacune des dépendances sortantes, cela augmente la complexité et les besoins de gestion.
• Si la dépendance sortante inclut des points de terminaison dans le réseau routable qui ne peuvent pas faire partie d’un pool back-end Azure Load Balancer, Private Link n’est pas applicable.

Pour surmonter ces deux limitations, déployez une solution proxy/NAT dans le spoke routable et rendez-la accessible à partir du réseau virtuel isolé à l’aide de Private Link.

Téléchargez un fichier PowerPoint de cette architecture.

Utilisez un seul point de terminaison privé ou un service Private Link pour exposer une solution proxy/NAT déployée dans le réseau routable. Les règles de traduction de port et de traduction d’adresses sont définies sur les appliances virtuelles réseau. Ces règles permettent d’utiliser un seul point de terminaison privé dans le réseau virtuel isolé pour accéder à plusieurs dépendances dans le réseau routable.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Federico Guerrini | Responsable technique EMEA
• Khush Kaviraj | Architecte de solutions cloud
• Jack Tracey | Architecte de solutions cloud senior

Autres contributeurs :

• Jodi Martis | Rédacteur technique

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Déployer le Pare-feu Azure dans un réseau virtuel
• Configurer SNAT dans le Pare-feu Azure
• Adresses IP prises en charge dans le réseau virtuel Azure
• Azure Private Link
• Équilibrage de charge Azure
• Peering de réseau virtuel

Ressources associées

• Conception de l’architecture réseau
• Approches architecturales pour la mise en réseau dans les solutions multilocataires
• Topologie de réseau hub-and-spoke