Réseau virtuel : adressage, appairage et connectivité hybride

Les darses avant les portiques

Sur Le Port, personne ne commence par les grues. On creuse d'abord les darses, on drague les chenaux, on pose le balisage qui dit par où passe un navire de trois cents mètres et par où il ne passe pas. Ensuite seulement on parle de portiques.

Ce tracé a une propriété désagréable : il est presque définitif. Ajouter un bassin au fond du terminal, c'est possible. Élargir un chenal déjà bordé d'entrepôts, beaucoup moins.

Le réseau virtuel est exactement cette couche-là. Il se pose avant les machines, avant les bases, avant les conteneurs, et il décide de ce qui sera possible après.

La nuance compte, parce que le raccourci « un plan d'adressage est immuable » est faux au sens strict. On peut ajouter une plage d'adresses à un réseau virtuel existant. En revanche, un sous-réseau ne se redimensionne ni ne se supprime tant qu'il contient une ressource, et un chevauchement d'adresses avec le réseau interne de l'entreprise ne se règle jamais autrement qu'en redéployant ce qui vit dedans.

Le réseau est la décision la plus coûteuse à défaire, non parce qu'elle est irréversible, mais parce que la défaire suppose de vider ce qui tourne déjà dessus.

Ce billet traite la construction à l'intérieur, puis le raccordement à l'extérieur. La répartition de charge et le filtrage du trafic ont leur propre billet, le suivant dans la série.

Ce qui est régional et ce qui ne l'est pas

Un terminal appartient à un bassin. Une voie ferrée, elle, traverse le pays. Confondre les deux échelles est la première erreur de conception.

Un réseau virtuel Azure vit dans une région et un abonnement. Il porte un ou plusieurs espaces d'adressage en notation CIDR, découpés en sous-réseaux. Toutes les ressources qui y sont attachées se joignent entre elles par défaut, sans configuration supplémentaire.

Autour de cet objet régional gravitent des services dont la portée est différente, et cette différence change les topologies possibles.

La topologie la plus répandue est le moyeu et les rayons. Un réseau central porte ce qui est mutualisé, la passerelle hybride, le pare-feu, la résolution de noms. Les réseaux applicatifs s'y raccrochent et n'exposent rien eux-mêmes.

Le moyeu répond à un besoin très concret : mutualiser une passerelle et un pare-feu au lieu d'en déployer un exemplaire dans chaque réseau applicatif.

Le plan d'adressage

Le balisage d'un chenal ne s'invente pas au moment où le navire arrive. On calcule le tirant d'eau, la largeur, la marge de manœuvre, et on ajoute de la marge pour les navires qui n'existent pas encore.

Trois règles cadrent le plan d'adressage, et la première est la plus violée.

Ne jamais chevaucher le réseau interne. Un espace d'adressage qui recoupe une plage déjà utilisée au siège ou dans une filiale interdit définitivement l'appairage et casse le raccordement hybride. Cela se vérifie avant de créer la première ressource, auprès de l'équipe qui tient le plan d'adressage de l'entreprise, pas après.

Prévoir la croissance. Un espace en /16 par région coûte exactement la même chose qu'un /24, puisque les adresses privées ne se facturent pas. Le réflexe de découper au plus juste vient du monde physique et n'a aucun sens ici.

Compter les adresses réservées. Azure en prélève cinq par sous-réseau : l'adresse de réseau, la passerelle par défaut, deux adresses pour le service de noms, et l'adresse de diffusion. Sur un grand sous-réseau, la ponction est indolore. Sur un petit, elle est décisive.

Certains services n'acceptent pas n'importe quel sous-réseau : ils en exigent un dédié, parfois portant un nom imposé au caractère près.

Le cas qui fait exploser les plans d'adressage est le cluster de conteneurs. Posons le calcul.

Avec le modèle réseau qui attribue à chaque pod une adresse du réseau virtuel, chaque nœud réserve à l'avance ses adresses de pods, qu'elles servent ou non. Sur un pool prévu pour monter à 50 nœuds avec 30 pods par nœud, la réservation vaut 50 × (30 + 1) = 1 550 adresses, auxquelles s'ajoutent les 5 réservées et la marge des nœuds temporaires créés pendant une montée de version. Un /22 offre 1 019 adresses utilisables : insuffisant. Il faut un /21.

Le même cluster en modèle superposé place les pods dans un espace d'adressage privé distinct du réseau virtuel. Le sous-réseau ne porte plus qu'une adresse par nœud, soit 50 adresses : un /26 suffit, avec de la marge. Trente-deux fois moins d'espace consommé, pour une décision prise en une ligne de configuration au moment de la création du cluster.

az network vnet create \
  --resource-group rg-reseau-moyeu \
  --name vnet-moyeu-westeurope \
  --address-prefixes 10.10.0.0/16 \
  --subnet-name GatewaySubnet \
  --subnet-prefixes 10.10.0.0/27

az network vnet subnet create \
  --resource-group rg-reseau-moyeu \
  --vnet-name vnet-moyeu-westeurope \
  --name AzureFirewallSubnet \
  --address-prefixes 10.10.1.0/26

Un sous-réseau ne se redimensionne pas tant qu'il contient une ressource. C'est ce qui justifie la marge : corriger le calibre après coup oblige à vider ce qui vit dedans.

Relier des réseaux

Deux bassins voisins ne communiquent pas parce qu'ils sont voisins. Il faut un chenal, et ce chenal relie exactement deux points.

L'appairage de réseaux virtuels crée ce chenal. Le trafic passe par le réseau fédérateur du fournisseur, pas par Internet, et les ressources se joignent par leurs adresses privées comme si elles partageaient un même réseau. Deux réseaux dans des régions différentes s'appairent de la même façon.

La propriété qui structure tout est la non-transitivité. Si le moyeu est appairé au rayon A et au rayon B, A ne parle pas à B. Le chenal relie deux bassins, il ne fait pas carrefour.

Trois sorties existent. Appairer directement A et B, ce qui donne un maillage dont le nombre de liens croît vite. Faire transiter par le moyeu, ce qui suppose une route définie manuellement pointant vers un pare-feu ou un équipement de routage dans le moyeu. Ou passer à Virtual WAN, dont le moyeu managé assure le routage de tous vers tous sans écrire une seule route.

L'appairage porte quatre interrupteurs qui décident de ce qui traverse.

az network vnet peering create \
  --resource-group rg-reseau-moyeu \
  --name moyeu-vers-rayon-applicatif \
  --vnet-name vnet-moyeu-westeurope \
  --remote-vnet vnet-app-westeurope \
  --allow-vnet-access \
  --allow-forwarded-traffic \
  --allow-gateway-transit

Côté rayon, l'appairage symétrique porte --use-remote-gateways : c'est ce qui permet au rayon d'emprunter la passerelle hybride du moyeu au lieu d'en déployer une à lui. Sans --allow-forwarded-traffic côté moyeu, le trafic qu'un pare-feu y relaie est rejeté, et le symptôme ressemble à s'y méprendre à une règle de filtrage mal écrite.

L'appairage ne fait jamais carrefour. Tout ce qui ressemble à du transitif dans Azure est soit une route écrite à la main, soit un service managé qui l'écrit pour vous.

Résoudre les noms

Connaître la position du quai 14 ne suffit pas : encore faut-il savoir quel navire y est attendu. Le tableau d'affectation compte autant que le balisage.

Par défaut, chaque réseau virtuel dispose d'un résolveur fourni par la plateforme, joignable à l'adresse 168.63.129.16. Il résout les noms publics et les noms des machines du même réseau virtuel. Il ne résout ni les noms internes de l'entreprise, ni les noms privés d'un autre réseau virtuel.

Les zones DNS privées comblent ce trou. Une zone se crée comme une ressource globale, puis se lie à un ou plusieurs réseaux virtuels. Sans ce lien, la zone existe et ne sert à rien : c'est l'oubli le plus fréquent du sujet.

az network private-dns zone create \
  --resource-group rg-reseau-moyeu \
  --name privatelink.blob.core.windows.net

az network private-dns link vnet create \
  --resource-group rg-reseau-moyeu \
  --zone-name privatelink.blob.core.windows.net \
  --name lien-rayon-applicatif \
  --virtual-network vnet-app-westeurope \
  --registration-enabled false

Le cas qui remplit le plus de tickets réseau est celui du point de terminaison privé. La ressource managée conserve son nom public, mais ce nom doit désormais renvoyer une adresse privée. Le mécanisme repose sur une zone dédiée, du type privatelink.blob.core.windows.net pour le stockage objet ou privatelink.database.windows.net pour les bases relationnelles, liée au bon réseau virtuel.

Reste le sens inverse, celui des machines du site interne qui doivent résoudre ces mêmes noms privés. Historiquement, on déployait une machine virtuelle jouant le redirecteur DNS dans le moyeu. Azure DNS Private Resolver rend ce bricolage inutile : un point de terminaison entrant permet au réseau interne d'interroger les zones privées, un point de terminaison sortant plus un jeu de règles de transfert permet à Azure d'interroger les serveurs de l'entreprise.

Un point de terminaison privé sans la zone DNS qui va avec ne produit pas d'erreur claire. Il produit un nom qui résout vers Internet, une connexion refusée par le pare-feu du service, et deux heures de recherche du côté du filtrage.

Le raccordement hybride

Le Port ne vit pas seul. Il est raccordé au réseau ferré national par une voie dédiée, et à l'arrière-pays par une route de desserte. La voie ferrée coûte cher, se négocie avec un opérateur, et met des mois à se poser. La route existe déjà.

Les deux mécanismes hybrides d'Azure suivent exactement cette opposition.

Le VPN site à site monte un tunnel IPsec entre une passerelle Azure et un équipement sur site, à travers Internet. Il se déploie dans la journée. La passerelle se configure en mode actif-actif pour survivre à la perte d'une instance, et sait annoncer ses routes en BGP. Il existe aussi un mode point à site, où c'est un poste isolé qui se connecte, utile pour l'administration et les postes nomades.

ExpressRoute ne passe pas par Internet. Un circuit est provisionné chez un opérateur partenaire, avec un appairage privé vers les réseaux virtuels et, si besoin, un appairage Microsoft vers les services accessibles par adresses publiques. Trois options comptent : FastPath, qui fait contourner la passerelle au trafic de données pour réduire la latence, Global Reach, qui permet à deux sites de l'entreprise de communiquer entre eux via le réseau de l'opérateur de cloud, et ExpressRoute Direct, qui raccorde l'entreprise directement à l'infrastructure sans intermédiaire.

Les deux coexistent, et c'est souvent la bonne réponse : un circuit dédié pour le trafic de production, un tunnel VPN en secours, avec un basculement piloté par BGP. Reste une limite qu'on découvre trop tard : un circuit unique, même livré en paire de connexions redondantes, dépend d'un seul site d'appairage. La résilience réelle commence à deux circuits sur deux sites distincts.

Un circuit dédié protège du débit variable et de la latence variable. Il ne protège pas de la panne du site d'appairage par lequel il entre.

Le routage

Le balisage indique le chemin par défaut. Un capitaine peut recevoir une consigne particulière qui prime sur le balisage, et c'est là que les collisions arrivent.

Azure installe des routes système dans chaque sous-réseau, sans qu'on les demande : à l'intérieur du réseau virtuel, vers les réseaux appairés, vers la passerelle hybride, et une route par défaut vers Internet. Une table de routes attachée à un sous-réseau ajoute des routes définies par l'utilisateur, qui prennent le pas sur les routes système.

az network route-table route create \
  --resource-group rg-reseau-moyeu \
  --route-table-name rt-rayon-applicatif \
  --name defaut-vers-pare-feu \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.10.1.4

Deux règles de sélection décident du reste. Le préfixe le plus spécifique gagne, comme partout. À spécificité égale, une route définie par l'utilisateur l'emporte sur une route apprise en BGP, qui l'emporte elle-même sur une route système.

Le tunnel forcé consiste à pousser 0.0.0.0/0 vers la passerelle hybride, pour que toute sortie Internet passe par le proxy et le filtrage de l'entreprise. C'est une exigence de conformité fréquente, et une source de pannes tout aussi fréquente : les services managés qui ont besoin de joindre le plan de contrôle du fournisseur se retrouvent coupés si les exceptions ne sont pas écrites.

Écrire une route par défaut vers un équipement de filtrage sans exclure explicitement le sous-réseau de cet équipement produit une boucle de routage. Le symptôme est un service qui ne répond plus du tout, pas un service lent.

Points de terminaison de service ou points de terminaison privés

Deux façons de faire entrer un entrepôt sous douane dans le périmètre du terminal. Soit on reconnaît le camion à l'entrée et on le laisse emprunter la voie interne, soit on construit un embranchement privé qui ne dessert que cet entrepôt.

Le point de terminaison de service relève du premier cas. Le sous-réseau est reconnu par le service managé, le trafic emprunte le réseau fédérateur du fournisseur, et le pare-feu du service n'accepte plus que ce sous-réseau. La ressource conserve néanmoins une adresse publique, et le mécanisme ne fonctionne pas depuis un site interne.

Le point de terminaison privé relève du second. Une carte réseau est créée dans votre sous-réseau, avec une adresse privée à vous, associée à une instance précise de la ressource. Le trafic n'a plus besoin de la moindre adresse publique, et fonctionne depuis le site interne à travers le lien hybride, à condition que la résolution de noms suive.

Le choix se tranche vite. Accès depuis le site interne ou besoin de cibler une instance et non un service entier : point de terminaison privé. Trafic strictement interne à la région, budget serré et plan d'adressage tendu : point de terminaison de service.

Le point de terminaison privé est la seule des deux options qui permette de couper l'accès public d'un service de données pour de bon. C'est aussi la seule qui casse dès que le DNS n'est pas configuré.

Scénario B : Facebook, le 4 octobre 2021

Le meilleur cas public sur ce que tiennent réellement le routage et la résolution de noms a été publié par l'entreprise elle-même, dans son compte rendu d'ingénierie sur la panne du 4 octobre 2021.

Ce jour-là, pendant une opération de maintenance de routine, une commande destinée à évaluer la capacité disponible du réseau fédérateur mondial a coupé l'ensemble des connexions de ce réseau. Les centres de données de l'entreprise se sont retrouvés déconnectés les uns des autres.

Un outil d'audit existait précisément pour interdire ce type de commande. Le compte rendu indique qu'un défaut dans cet outil l'a empêché de la bloquer.

La suite tient à un enchaînement de conception. Les serveurs de noms faisant autorité de l'entreprise annoncent leurs routes en BGP, et sont conçus pour retirer ces annonces s'ils perdent le contact avec les centres de données. Le réseau fédérateur étant tombé, ils ont fait exactement ce pour quoi ils avaient été programmés : ils se sont retirés d'Internet. Plus aucun nom ne résolvait, donc plus aucun service n'était joignable, y compris ceux qui fonctionnaient encore parfaitement.

Le compte rendu détaille ensuite ce qui a rendu la reprise si longue. Les outils internes utilisés pour diagnostiquer et corriger reposaient sur le même réseau et le même DNS, et étaient donc hors service. Il a fallu envoyer des ingénieurs physiquement sur les sites, où l'accès et la remise en service du matériel se sont révélés lents par construction. L'interruption a duré plusieurs heures.

Une panne de routage et une panne de résolution de noms ne dégradent pas un service : elles le font disparaître. Et elles emportent avec elles les outils censés servir à le réparer.

L'image portuaire est directe. Si le balisage disparaît et que le registre des postes d'amarrage devient illisible, il ne sert à rien que les quais soient intacts et les portiques en état de marche : plus aucun navire ne sait où accoster. Le port n'est pas endommagé, il est simplement devenu introuvable.

La transposition côté conception se lit en deux points. Le plan de routage et la résolution de noms sont des dépendances de premier rang, au même titre que l'identité. Et le chemin d'administration doit être conçu pour survivre à la panne du chemin de production, ce qui interdit de le faire reposer sur les mêmes zones DNS privées et le même tunnel unique.

Points clés

• L'espace d'adressage se négocie avant la première ressource. Un chevauchement avec le réseau interne interdit définitivement l'appairage et le raccordement hybride, et ne se corrige qu'en redéployant.
• Les cinq adresses réservées par sous-réseau changent tout sur les petits calibres. Un /29 offre trois adresses utilisables, un /24 en offre 251.
• Le modèle réseau d'un cluster de conteneurs pèse plus lourd que tout le reste. Cinquante nœuds à trente pods réservent 1 550 adresses, soit un /21, contre un /26 en modèle superposé.
• L'appairage n'est pas transitif. Le trafic entre deux rayons passe par une route écrite à la main vers le moyeu, ou par un service managé qui l'écrit à votre place.
• Le point de terminaison privé ne fonctionne qu'avec la zone DNS privée liée au bon réseau virtuel. Sans elle, le nom résout vers une adresse publique et le diagnostic part dans la mauvaise direction.

Dans la série

Palier 2 : Construire les terminaux. Domaine : Réseau & connectivité.

• Précédent : Intégration de données : lot, flux et entrepôt
• Suivant : Répartition de charge et sécurité réseau : quatre services, cinq filtres
• Vue d'ensemble : Concevoir sur Azure : par où commencer

Pour aller plus loin

• Répartition de charge et sécurité réseau : quatre services, cinq filtres, la suite immédiate : aiguiller le trafic vers le bon quai, puis le filtrer.
• Zone d'atterrissage et déploiement automatisé, où le plan d'adressage et la topologie moyeu et rayons sont produits par du code plutôt qu'à la main.
• Compte rendu d'ingénierie de Meta sur la panne du 4 octobre 2021 : la chronologie, le retrait des annonces BGP et l'effet sur les outils internes.
• Vue d'ensemble du réseau virtuel Azure et routage du trafic dans un réseau virtuel : les routes système et les types de saut suivant, dans le détail.
• Configuration DNS des points de terminaison privés : la liste des zones privatelink par service, à garder sous la main.
• Introduction à ExpressRoute : types d'appairage, options de redondance et fonctionnement des circuits.