Aller au contenu
English
Cloud high

Rappels réseau : IP, CIDR, routage, DNS et NAT

17 min de lecture

Avant de créer le moindre réseau dans le cloud, vous devez savoir répondre à une question : quelle plage d'adresses vais-je réserver, et pour combien de machines ? C'est la seule décision réseau qu'un fournisseur cloud vous laisse rarement corriger après coup. Cette page reprend les notions d'adressage, de découpage et de routage dont vous aurez besoin dans tout le reste du parcours, en partant du principe que vous n'en avez jamais fait. Elle s'adresse à qui sait utiliser un terminal Linux et veut comprendre ce qui se passe sous les objets « réseau » des consoles cloud.

  • Lire une adresse IP et sa notation CIDR sans calculatrice.
  • Découper une plage en sous-réseaux qui tiennent dans la durée.
  • Suivre le trajet d'un paquet à travers une table de routage.
  • Expliquer ce que fait le NAT, et pourquoi il apparaît sur votre facture.
  • Éviter le chevauchement d'adresses, l'erreur qui interdit d'interconnecter deux réseaux.

Aucun prérequis réseau. Des bases de ligne de commande Linux suffisent pour rejouer les exemples, tous exécutables sur votre machine.

Une adresse IP identifie une interface réseau, pas une machine. La nuance paraît byzantine et elle explique la moitié des incompréhensions du cloud : une machine virtuelle avec deux cartes réseau porte deux adresses, et une même machine peut changer d'adresse sans changer d'identité.

En IPv4, l'adresse tient sur 32 bits, que l'on écrit en quatre nombres de 0 à 255 séparés par des points, par exemple 10.42.7.19. Chaque nombre représente huit bits, ce qu'on appelle un octet. Cela donne un peu plus de quatre milliards d'adresses possibles, ce qui semblait immense en 1981 et ne l'est plus du tout.

Cette pénurie a une conséquence directe sur votre travail : les adresses publiques sont rares et facturées, les adresses privées sont gratuites et réutilisables par tout le monde. Trois plages sont réservées à l'usage privé et ne sont routables nulle part sur Internet.

Plage privéeNotation CIDRNombre d'adressesUsage habituel dans le cloud
10.0.0.0 à 10.255.255.25510.0.0.0/816 777 216Le choix par défaut, assez vaste pour découper
172.16.0.0 à 172.31.255.255172.16.0.0/121 048 576Utilisée par défaut par Docker, attention aux collisions
192.168.0.0 à 192.168.255.255192.168.0.0/1665 536Les box et réseaux domestiques, à éviter en entreprise

Le nombre après la barre oblique indique combien de bits sont figés au début de l'adresse ; tout le reste est disponible pour numéroter les machines. C'est toute la notation CIDR, le reste n'est que de l'arithmétique.

Dans 10.0.1.0/24, les 24 premiers bits (soit 10.0.1) identifient le réseau, et les 8 bits restants numérotent les machines : de 10.0.1.0 à 10.0.1.255, donc 256 adresses. Chaque bit rendu aux machines double leur nombre.

NotationAdresses au totalUtilisables (AWS, Azure)Ce que ça dimensionne
/281611Un petit sous-réseau de bases de données
/24256251Le sous-réseau standard, la valeur par défaut de la plupart des exemples
/204 0964 091Un environnement complet avec de la marge
/1665 53665 531Un réseau privé entier, découpable ensuite

Le nombre d'adresses utilisables est toujours inférieur au total, et le cloud en prend plus que le réseau traditionnel. Sur un réseau classique, deux adresses sont perdues : la première désigne le réseau lui-même, la dernière sert à la diffusion générale (le broadcast). Les fournisseurs cloud en réservent davantage, pour la passerelle, le service DNS et un usage futur.

FournisseurAdresses réservées par sous-réseauUtilisables dans un /24
AWS5251
Azure5251
Google Cloud4252

Cela ne se remarque pas sur un /24. Sur un /28, quatre ou cinq adresses réservées sur seize, c'est près d'un tiers de la plage qui part avant votre première machine. Vérifiez la valeur exacte de votre fournisseur avant de descendre sous le /26 : c'est le genre de détail qui transforme un sous-réseau « assez grand » en sous-réseau plein.

Prévoyez large sur le réseau, serré sur les sous-réseaux. La raison est asymétrique : chez la plupart des fournisseurs, la plage du réseau privé ne peut plus être modifiée après création, alors qu'un sous-réseau supplémentaire s'ajoute en une commande.

Une règle qui tient dans la durée pour un projet ordinaire :

  • le réseau en /16, par exemple 10.20.0.0/16, ce qui laisse 65 536 adresses ;
  • chaque sous-réseau en /24, ce qui en autorise 256 dans le réseau, largement au-delà de vos besoins ;
  • une tranche par environnement, pour que production et préproduction ne partagent aucune adresse.

Ce dimensionnement ne coûte rien de plus. Les adresses privées sont gratuites, et un réseau vaste n'est pas facturé plus cher qu'un réseau étroit. La seule chose que vous consommez, c'est votre propre plan d'adressage.

Une table de routage est une liste de règles du type « pour aller vers cette destination, passe par là », consultée de la plus précise à la plus générale. Une machine ne connaît pas Internet : elle connaît son voisinage immédiat et une sortie de secours pour tout le reste.

Regardez la table de votre propre machine :

Fenêtre de terminal
ip route show
default via 192.168.1.1 dev enp2s0 proto dhcp src 192.168.1.71 metric 100
192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.71 metric 100

Deux règles, et elles suffisent. La seconde dit : « les adresses de 192.168.1.0/24 sont sur mon réseau local, je les joins directement ». La première, default, dit : « pour tout le reste, donne le paquet à 192.168.1.1 », c'est-à-dire la box, qui se débrouillera.

La règle la plus spécifique gagne toujours. Si votre table contient à la fois 0.0.0.0/0 (tout Internet) et 10.20.5.0/24, un paquet destiné à 10.20.5.9 emprunte la seconde, parce qu'un /24 est plus précis qu'un /0. C'est ce mécanisme qui permet d'insérer un pare-feu ou un tunnel sur une destination précise sans toucher au reste du trafic.

Dans le cloud, vous n'écrivez pas ces règles dans les machines : vous les écrivez dans une table de routage attachée à un sous-réseau, et le fournisseur les applique à toutes les machines qui s'y trouvent. C'est le sujet de la leçon sur les tables de routage et les passerelles.

Le NAT, et pourquoi il apparaît sur votre facture

Section intitulée « Le NAT, et pourquoi il apparaît sur votre facture »

La traduction d'adresses, ou NAT, permet à des machines sans adresse publique de joindre Internet en empruntant l'adresse publique d'un intermédiaire. C'est ce que fait votre box depuis toujours : vos appareils portent des adresses privées, et le monde extérieur ne voit que l'adresse publique de la box.

Le mécanisme est un jeu d'écriture. Quand votre serveur privé 10.20.1.5 contacte un dépôt de paquets, la passerelle NAT remplace l'adresse source par la sienne, note la correspondance dans une table, et fait le remplacement inverse sur la réponse. On parle de PAT quand plusieurs machines partagent la même adresse publique et sont distinguées par le numéro de port, ce qui est le cas courant.

La conséquence de fond est une asymétrie : le NAT laisse sortir, il ne laisse pas entrer. Une machine derrière une passerelle NAT peut télécharger ses mises à jour et appeler une API externe, mais personne sur Internet ne peut initier une connexion vers elle. C'est une propriété de sécurité que l'on obtient gratuitement, et sur laquelle beaucoup d'architectures reposent sans le dire.

Le DNS traduit un nom en adresse, et cette traduction est mise en cache à chaque étape du chemin. Retenez surtout la seconde partie de la phrase : c'est elle qui explique pourquoi votre changement « ne prend pas ».

Première idée, la résolution est récursive. Votre machine demande à un résolveur, qui interroge à son tour les serveurs faisant autorité, du plus général au plus précis, jusqu'à obtenir la réponse. Vous pouvez suivre ce cheminement :

Fenêtre de terminal
dig +trace blog.stephane-robert.info

Deuxième idée, chaque enregistrement porte une durée de vie, le TTL, exprimée en secondes. Tant qu'elle n'est pas écoulée, les caches répondent l'ancienne valeur, quoi que vous ayez modifié.

Fenêtre de terminal
dig +noall +answer blog.stephane-robert.info
blog.stephane-robert.info. 3600 IN CNAME d10xniuqja0kdi.cloudfront.net.
d10xniuqja0kdi.cloudfront.net. 60 IN A 13.227.173.18

Deux enseignements dans ces deux lignes. Le nom du site ne pointe pas vers une adresse mais vers un autre nom, celui d'un réseau de diffusion de contenu : c'est un CNAME, et c'est le montage habituel dès qu'on place un cache devant un site. Et les nombres 3600 puis 60 sont les TTL : une heure pour l'alias, une minute seulement pour l'adresse finale, ce qui permet au diffuseur de changer de serveur très vite.

Un TTL de 86400, soit un jour, signifierait qu'une bascule met vingt-quatre heures à être vue partout.

Troisième idée, quelques types d'enregistrements suffisent au quotidien.

TypeCe qu'il associeExemple d'usage
Aun nom vers une adresse IPv4www vers 203.0.113.10
AAAAun nom vers une adresse IPv6www vers 2001:db8::10
CNAMEun nom vers un autre nomwww vers le nom d'un répartiteur de charge
MXle serveur de messagerie du domainerecevoir du courrier
TXTdu texte librepreuves de propriété, enregistrements SPF

IPv6 n'est pas « IPv4 avec plus d'adresses », c'est un protocole distinct qui cohabite avec lui. Une adresse y tient sur 128 bits, notée en hexadécimal séparé par des deux-points, comme 2001:db8:1::10, avec une abréviation qui remplace la plus longue suite de zéros par ::.

Ce que cela change concrètement, une fois passée la nouveauté de l'écriture :

  • le NAT disparaît, chaque machine pouvant porter une adresse publique, ce qui simplifie le routage et rend visible une responsabilité qui existait déjà : le filtrage a toujours été le travail du pare-feu, l'absence de NAT retire simplement l'illusion qu'autre chose s'en chargeait ;
  • les plages sont vastes, un /64 par sous-réseau est la norme, et découper plus finement casse l'autoconfiguration ;
  • la double pile est le mode de déploiement courant, les deux protocoles fonctionnant en parallèle sur les mêmes machines.

Le sujet a sa propre leçon, IPv6 dans le cloud, car les fournisseurs le traitent de façons assez différentes.

Ces commandes fonctionnent sur n'importe quelle machine Linux, sans compte cloud. Elles valent mieux qu'une relecture.

  1. Calculer un découpage

    Fenêtre de terminal
    ipcalc 10.20.0.0/16

    Vérifiez que vous savez dire, sans le lire, combien d'adresses contient ce réseau et quelle est la dernière.

  2. Lire votre table de routage

    Fenêtre de terminal
    ip route show

    Identifiez la route default et dites vers quelle adresse elle envoie.

  3. Suivre le trajet réel d'un paquet

    Fenêtre de terminal
    ip route get 1.1.1.1

    La réponse nomme l'interface et la passerelle retenues. C'est exactement le raisonnement que fait une table de routage cloud.

  4. Observer un TTL diminuer

    Fenêtre de terminal
    dig +noall +answer blog.stephane-robert.info
    sleep 10
    dig +noall +answer blog.stephane-robert.info

    Le TTL de la seconde réponse est inférieur : votre résolveur a répondu depuis son cache, et il décompte. Relevé sur ce domaine, 3600 est tombé à 54 en quelques secondes, l'entrée ayant déjà passé un moment en cache.

  • Une adresse IP identifie une interface, pas une machine ; une machine à deux cartes porte deux adresses.
  • Le nombre après le / compte les bits figés. Chaque bit rendu aux machines double leur nombre.
  • Le cloud réserve cinq adresses par sous-réseau, contre deux sur un réseau classique. Sur un /28, c'est un tiers de la plage.
  • Changer la plage d'un réseau en production coûte cher, même quand le fournisseur permet d'en ajouter une seconde : prévoyez large dès le départ, un /16 découpé en /24 étant un bon point de départ pour un laboratoire ou un premier environnement.
  • N'utilisez pas 192.168.x.x pour un réseau cloud : c'est la plage des box, et elle rendra tout VPN inutilisable.
  • La route la plus spécifique gagne, ce qui permet de dévier un flux précis sans toucher au reste.
  • Le NAT laisse sortir et pas entrer, mais ce n'est pas un dispositif de sécurité. L'absence de traduction empêche une connexion entrante non sollicitée d'aboutir, et c'est tout : le trafic de retour d'une connexion sortante passe toujours, y compris celui d'une machine compromise, et une redirection de port ouvre le passage sans qu'aucune règle ne l'exprime. Le filtrage reste le travail du pare-feu et des groupes de sécurité. C'est aussi une ligne de facture, à l'heure et au gigaoctet.
  • Baissez le TTL avant une bascule DNS, jamais pendant.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracking. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn