Planifier l’adressage IP

Il est important que votre organisation planifie l’adressage IP dans Azure. La planification garantit qu’il n’existe pas de chevauchement des espaces d’adressage IP des emplacements locaux et des régions Azure concernés.

Remarques relatives à la conception :

• Le chevauchement d’espaces d’adressage IP dans des emplacements locaux et régions Azure occasionne des problèmes majeurs en termes de contention.

• La passerelle VPN Azure peut connecter des sites locaux se chevauchant avec des espaces d’adressage IP se chevauchant via la fonctionnalité de traduction d’adresses réseau (NAT). Cette fonctionnalité est en disponibilité générale dans Azure Virtual WAN et dans la version autonome d’Azure VPN Gateway.

  

• Vous pouvez ajouter un espace d’adressage après avoir créé votre réseau virtuel. Ce processus n’a pas besoin d’une interruption si le réseau virtuel est déjà connecté à un autre réseau virtuel par le biais de l’appairage de réseaux virtuels. Au lieu de cela, chaque appairage distant a besoin qu’une opération de resynchronisation soit effectuée suite à la modification de l’espace réseau.

• Azure réserve cinq adresses IP dans chaque sous-réseau. Prenez en compte ces adresses lorsque vous dimensionnez des réseaux virtuels et les sous-réseaux qu’ils englobent.

• Certains services Azure nécessitent des sous-réseaux dédiés. Ces services sont le Pare-feu Azure et la passerelle VPN Azure.

• Vous pouvez déléguer des sous-réseaux à certains services pour créer des instances de ceux-ci à l’intérieur du sous-réseau.

Recommandations relatives à la conception :

• Planifiez à l’avance des espaces d’adressage IP qui ne se chevauchent pas dans les régions Azure et les emplacements locaux.

• Utilisez des adresses IP de l’allocation d’adresses pour l’Internet privé, appelées adresses RFC 1918.

• N’utilisez pas les plages d’adresses suivantes :

  • 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)

• Pour les environnements au sein desquels la disponibilité des adresses IP privées est limitée, vous pouvez utiliser le protocole IPv6. Les réseaux virtuels peuvent être IPv4 seulement ou à double pile IPv4 + IPv6.

  

• Ne créez pas de grands réseaux virtuels tels que /16. Cela permet de s’assurer que l’espace d’adressage IP n’est pas gaspillé. Le plus petit sous-réseau IPv4 pris en charge est /29 et le plus grand est /2 lorsque des définitions de sous-réseaux CIDR (Classless Inter-Domain Routing). La taille des sous-réseaux IPv6 doit être exactement de /64.

• Ne créez pas de réseaux virtuels sans planifier à l’avance l’espace d’adressage requis.

• N’utilisez pas d’adresses IP publiques pour les réseaux virtuels, en particulier si les adresses IP publiques n’appartiennent pas à votre organisation.

• Dans les services que vous allez utiliser, certains ont des IP réservées (Adresses IP), comme AKS avec réseau CNI

• Utilisez des réseaux virtuels spoke de zone d’atterrissage non routables et le service Azure Private Link pour empêcher l’épuisement IPv4.

Considérations relatives à IPv6

Un nombre croissant d’organisations adoptent IPv6 dans leurs environnements. Cette adoption est motivée par l'épuisement de l'espace IPv4 public, la pénurie d'IPv4 privé, en particulier dans les réseaux à grande échelle, et la nécessité de fournir une connectivité aux clients exclusivement IPv6. Il n'y a pas d'approche universelle pour l'adoption de l'IPv6. Il existe cependant des meilleures pratiques à suivre lorsque vous planifiez l'IPv6 et que vous le mettez en œuvre dans vos réseaux Azure existants.

Microsoft Cloud Adoption Framework pour Azure vous aide à comprendre les considérations à prendre en compte lorsque vous créez des systèmes dans le cloud. Pour en savoir plus sur les meilleures pratiques architecturales pour la conception de systèmes durables, consultez les principes de conception des zones d’atterrissage Azure. Pour obtenir des recommandations détaillées et des meilleures pratiques concernant votre architecture cloud, notamment les déploiements d’architecture de référence, les diagrammes et les guides, consultez le Guide du centre d'architecture pour l'IPv6.

Considérations relatives à la conception :

• Phase de votre adoption IPv6. En fonction des besoins de votre entreprise, implémentez IPv6 si nécessaire. N’oubliez pas que IPv4 et IPv6 peuvent coexister aussi longtemps que nécessaire.

• Dans les scénarios où les applications s’appuient sur des services IaaS (Infrastructure as a Service) qui ont une prise en charge complète de IPv6, comme les machines virtuelles, l’utilisation native de bout en bout d’IPv4 et IPv6 est possible. Cette configuration évite les complications de traduction et fournit les informations les plus précises au serveur et à l’application.

  Vous pouvez déployer des répartiteurs de charge Azure Basic-SKU orientés vers l'internet avec une adresse IPv6. Cette configuration permet une connectivité IPv6 native de bout en bout entre l'internet public et les machines virtuelles Azure via l'équilibrage de charge. Cette approche facilite également les connexions sortantes natives de bout en bout entre les machines virtuelles et les clients IPv6 sur l'internet public. Notez que cette approche nécessite que chaque appareil du chemin d'accès gère le trafic IPv6.

  L’approche native de bout en bout est la plus utile pour la communication de serveur à serveur direct ou client à serveur. Il n'est pas utile pour la plupart des services web et applications, qui sont généralement protégés par des pare-feux, des pare-feux d'application web ou des proxys inverses.

• Certains déploiements et applications complexes qui utilisent une combinaison de services tiers, de services de plateforme en tant que service (PaaS) et de solutions dorsales peuvent ne pas prendre en charge l'IPv6 natif. Dans ce cas, vous devez utiliser NAT/NAT64 ou une solution de proxy IPv6 pour permettre la communication entre IPv6 et IPv4.

• Lorsque la complexité de l'architecture de l'application ou d'autres facteurs tels que les coûts de formation sont considérés comme importants, vous pouvez continuer à utiliser l'infrastructure IPv4 uniquement au niveau du back-end et déployer une passerelle à double pile IPv4/IPv6 d'une appliance virtuelle de réseau (NVA) tierce pour la fourniture de services.

  Un déploiement typique utilisant un NVA peut ressembler à ceci :

  

Recommandations relatives à la conception :

Voici un aperçu de ce que peut être une architecture typique :

• Déployez le dispositif virtuel de réseau dans Virtual Machine Scale Sets avec orchestration flexible (VMSS Flex) pour la résilience et exposez-les à Internet via Azure Load-Balancer, qui a une adresse IP publique front-end.

  Les NVA acceptent le trafic IPv4 et IPv6 et le traduisent en trafic IPv4 uniquement pour accéder à l'application dans le sous-réseau de l'application. L’approche réduit la complexité de l’équipe d’application et réduit la surface d’attaque.

• Déployez Azure Front Door pour assurer le routage global du trafic web.

  Les fonctionnalités d'Azure Front Door comprennent le proxy des requêtes et du trafic des clients IPv6 vers un back-end IPv4 uniquement, comme illustré ici :

  

Ce sont les principales différences entre l'approche NVA et l'approche Azure Front Door :

• Les NVA sont gérés par le client, fonctionnent à la couche 4 du modèle OSI et peuvent être déployés dans le même réseau virtuel Azure que l'application, avec une interface privée et publique.
• Azure Front Door est un service PaaS Azure global et fonctionne au niveau de la couche 7 (HTTP/HTTPS). Le back-end de l’application est un service accessible sur Internet qui peut être verrouillé pour accepter uniquement le trafic d’Azure Front Door.

Dans les environnements complexes, vous pouvez utiliser une combinaison des deux. Les NVA sont utilisées dans le cadre d'un déploiement régional. Azure Front Door est utilisé pour acheminer le trafic vers un ou plusieurs déploiements régionaux dans différentes régions Azure ou vers d'autres emplacements orientés vers l'internet. Pour déterminer la meilleure solution, nous vous recommandons d'examiner les capacités d'Azure Front Door et la documentation du produit.

Blocs CIDR du réseau virtuel IPv6 :

• Vous pouvez associer un seul bloc CIDR (Classless Inter-Domain Routing) IPv6 lorsque vous créez un nouveau réseau virtuel dans un déploiement Azure existant dans votre abonnement. La taille du sous-réseau pour IPv6 doit être /64. L'utilisation de cette taille garantit la compatibilité future si vous décidez d'activer le routage du sous-réseau vers un réseau sur site. Certains routeurs ne peuvent accepter que des itinéraires IPv6 de type /64.
• Si vous disposez d'un réseau virtuel existant qui ne prend en charge qu'IPv4 et de ressources dans votre sous-réseau qui sont configurées pour n'utiliser qu'IPv4, vous pouvez activer la prise en charge d'IPv6 pour votre réseau virtuel et vos ressources. Votre réseau virtuel peut fonctionner en mode double pile, ce qui permet à vos ressources de communiquer sur IPv4, IPv6 ou les deux. Les communications IPv4 et IPv6 sont indépendantes les unes des autres.
• Vous ne pouvez pas désactiver la prise en charge d'IPv4 pour votre réseau virtuel et vos sous-réseaux. IPv4 est le système d'adressage IP par défaut pour les réseaux virtuels Azure.
• Associez un bloc CIDR IPv6 à votre réseau et sous-réseau virtuels ou BYOIP IPv6. La notation CIDR est une méthode de représentation d'une adresse IP et de son masque de réseau. Les formats de ces adresses sont les suivants :
  • Une adresse IPv4 individuelle est composée de 32 bits, avec quatre groupes de trois chiffres décimaux. Par exemple : 10.0.1.0.
  • Un bloc CIDR IPv4 se compose de quatre groupes de trois chiffres décimaux, compris entre 0 et 255, séparés par des points, suivis d'une barre oblique et d'un nombre compris entre 0 et 32. Par exemple : 10.0.0.0/16.
  • Une adresse IPv6 individuelle est de 128 bits. Il comporte huit groupes de quatre chiffres hexadécimaux. Par exemple : 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
  • Un bloc CIDR IPv6 comprend quatre groupes de quatre chiffres hexadécimaux, séparés par des deux-points, suivis d'un double deux-points, puis d'une barre oblique et d'un nombre compris entre 1 et 128. Par exemple : 2001:db8:1234:1a00::/64.
• Mettez à jour vos tables de routage pour acheminer le trafic IPv6. Pour le trafic public, créez un itinéraire qui achemine tout le trafic IPv6 du sous-réseau vers passerelle VPN ou une passerelle Azure ExpressRoute.
• Mettez à jour vos règles de groupe de sécurité pour inclure des règles pour les adresses IPv6. Cela permet au trafic IPv6 de circuler vers et depuis vos instances. Si vous avez des règles de groupe de sécurité réseau pour contrôler le flux de trafic vers et depuis votre sous-réseau, vous devez inclure des règles pour le trafic IPv6.
• Si votre type d'instance ne prend pas en charge IPv6, utilisez la double pile ou déployez un NVA, comme décrit précédemment, qui traduit d'IPv4 à IPv6.

Outils de Gestion des adresses IP (IPAM)

L’utilisation d’un outil IPAM peut vous aider à planifier les adresses IP dans Azure, car il fournit une gestion et une visibilité centralisées, empêchant les chevauchements et les conflits dans les espaces d’adressage IP. Cette section vous guide tout au long des considérations et recommandations essentielles lors de l’adoption d’un outil IPAM.

Considérations relatives à la conception :

De nombreux outils IPAM sont disponibles pour votre considération, en fonction de vos besoins et de la taille de votre organisation. Les options vont d’un inventaire de base sur Excel à une solution open source pilotée par la communauté ou à des produits d’entreprise complets avec des fonctionnalités et un support avancés.

• Tenez compte de ces facteurs lors de l’évaluation de l’outil IPAM à implémenter :

  • Fonctionnalités minimales requises par votre organisation
  • Coût total de possession (TCO), y compris les licences et la maintenance continue
  • Journaux d'audit, enregistrement et contrôles d’accès en fonction du rôle
  • Authentification et autorisation avec Microsoft Entra ID
  • Accessible via l’API
  • Intégrations à d’autres outils et systèmes de gestion du réseau
  • Support communautaire actif ou niveau de support du fournisseur de logiciels

• Envisagez d’évaluer un outil IPAM open source comme Azure IPAM. Azure IPAM est une solution légère basée sur la plateforme Azure. Elle détecte automatiquement l’utilisation d’adresses IP au sein de votre locataire Azure et vous permet de tout gérer à partir d’une interface utilisateur centralisée ou via une API RESTful.

• Tenez compte du modèle d’exploitation de votre organisation et de la propriété de l’outil IPAM. L’objectif de l’implémentation d’un outil IPAM est de simplifier le processus de demande de nouveaux espaces d’adressage IP pour les équipes d’application sans dépendances et goulots d’étranglement.

• Une partie importante de la fonctionnalité de l’outil IPAM consiste à inventorier l’utilisation de l’espace d’adressage IP et à l’organiser logiquement.

Recommandations relatives à la conception :

• Le processus de réservation des espaces d’adressage IP qui ne se chevauchent pas doit prendre en charge la demande de différentes tailles en fonction des besoins des zones d’atterrissage d’application individuelles.

  • Par exemple, vous pouvez adopter la méthode de dimensionnement des T-shirts pour permettre aux équipes d’application de décrire facilement leurs besoins :
    • S - /24 - 256 adresses IP
    • M - /22 - 1 024 adresses IP
    • L - /20 - 4 096 adresses IP

• Votre outil IPAM doit avoir une API pour réserver des espaces d’adressage IP qui ne se chevauchent pas afin de prendre en charge une approche IaC (Infrastructure as Code). Cette fonctionnalité est également cruciale pour l’intégration transparente d’IPAM dans votre processus de distributeur d'abonnements, réduisant ainsi le risque d’erreurs et la nécessité d’une intervention manuelle.

  • Bicep avec sa fonctionnalité de script de déploiement ou les sources de données de Terraform afin d’extraire dynamiquement des données à partir de l’API IPAM sont des exemples d’approche IaC.

• Créez une disposition systématique pour vos espaces d’adressage IP en les structurant en fonction des régions Azure et des archétypes de charge de travail, garantissant ainsi un inventaire de réseau propre et traçable.

• Le processus de désaffectation des charges de travail doit inclure la suppression des espaces d’adressage IP qui ne sont plus utilisés, qui peuvent être réaffectés ultérieurement aux nouvelles charges de travail à venir, ce qui favorise une utilisation efficace des ressources.