Les deux automates de prêt installés en septembre à la médiathèque de Quimper atteignent internet et n'atteignent pas le catalogue, qui tient sur un serveur posé à vingt mètres d'eux. Le poste de la banque de prêt, lui, l'atteint sans difficulté. La personne envoyée a été prévenue que « le réseau est tombé », ce qu'il n'est manifestement pas.
C'est la panne qui termine la confiance de la plupart des gens en réseau, et pour une seule raison : une adresse, un nom et une route s'apprennent comme trois faits séparés, et une vraie panne est la question de savoir lequel des trois ment. En France il y a un quatrième menteur possible, il est là depuis vingt ans, et presque aucun tutoriel ne le mentionne : la famille d'adresses.
Le masque décide qui est local, et c'est la première question
Le serveur du catalogue est en 10.42.5.11, les automates en 10.42.6.40 et 10.42.6.41. Que cela compte ou non se décide entièrement sur un nombre. Le masque décide quelles adresses sont locales et lesquelles passent par un routeur. En /24, seuls les trois premiers nombres forment le réseau local, donc 10.42.5 et 10.42.6 sont deux réseaux et chaque paquet entre eux doit être routé. En /22, ce serait un seul réseau et le trafic ne quitterait jamais le commutateur.
C'est la question à poser en premier parce qu'elle se règle sans rien démonter et qu'elle disculpe ou accuse une machine entière. À Quimper, les trois machines portaient le même /22 distribué par le même serveur DHCP : même réseau, aucun routeur dans l'histoire, et la piste s'arrête là. Un masque juste n'est pas un réseau qui marche, c'est un suspect en moins, et c'est exactement ce que vaut une bonne question.
La famille d'adresses, l'étage que les tutoriels n'ont pas
La France a basculé tôt. Free a activé l'IPv6 chez ses abonnés à partir de 2007, avec une technique, le 6rd, conçue dans ses propres murs, et les autres opérateurs ont suivi ; l'ARCEP publie chaque année un baromètre de la transition vers IPv6 qui suit ligne à ligne où en est le pays. La conséquence pour un lecteur français est concrète et permanente : sa machine porte deux adresses, elle a le choix entre deux chemins pour chaque nom, et le tutoriel qu'il est en train de suivre a été écrit comme s'il n'y en avait qu'un. Chaque question de cette page se pose donc deux fois.
Le catalogue de Quimper répond à un nom, et ce nom a deux enregistrements parce que l'installateur en a créé un de chaque. Ce que la machine en fait se lit d'une commande : getent hosts catalogue.bib.example imprime les adresses dans l'ordre où la machine les essaiera, la famille IPv6 d'abord. Les deux automates partaient donc vers une adresse IPv6 pendant que le poste de la banque de prêt, lui, arrivait à destination.
Quatre commandes séparent les deux moitiés de cette histoire, et aucune ne demande de droits particuliers.
getent hosts catalogue.bib.exampleimprime ce que cette machine va utiliser, et non ce qu'un serveur de noms répond dans l'absoluss -tlnpsur le serveur donne les sockets en écoute, la famille de chacune et le processus qui la tientping -6etping -4imposent une famille et transforment une panne floue en deux essaismtr -r -c 20 catalogue.bib.examplemêle ping et traceroute et montre à quel saut la perte commence
La réponse était sur le serveur. Dans ss, 0.0.0.0:8080 est IPv4 seul et [::]:8080 écoute les deux familles, et le service du catalogue affichait la première forme. Rien n'était cassé : un logiciel configuré pour écouter en IPv4 fait exactement ce qu'on lui a demandé, le noyau refuse proprement les connexions IPv6 entrantes, et aucun journal ne consigne un refus propre. La panne était donc entièrement décrite par une ligne de configuration et par un enregistrement de nom qui promettait un chemin que personne n'écoutait.
Reste la partie qui explique pourquoi personne ne l'avait vue. Un navigateur rattrape une famille cassée, une commande ne la rattrape pas. Un navigateur ouvre les deux familles presque en même temps et garde celle qui répond, ce que décrit la RFC 8305 ; l'usager ne voit rien du tout. ping -6 et ping -4 forcent la famille d'adresses et séparent deux pannes, et c'est pourquoi la panne était invisible depuis le navigateur du bibliothécaire et évidente en deux commandes. L'outil le plus utilisé est celui qui cache le mieux.
Ce que l'IPv4 partagée retire sans le dire
L'autre moitié de la bascule française se voit à l'envers, quand on veut être joint plutôt que joindre. Derrière une IPv4 partagée, aucune connexion entrante n'aboutit, et rien ne le signale. Une ligne mobile est dans ce cas depuis toujours et une part croissante des offres fixes l'est aussi, l'adresse publique étant alors mutualisée entre plusieurs abonnés. Une caméra, un serveur de jeu, un accès distant à la maison : la redirection de port est configurée correctement dans la box, elle ne peut simplement rien rediriger, puisque l'adresse publique n'appartient pas à cet abonné. L'IPv6, où chaque appareil porte une adresse à lui, est la sortie, et c'est la raison pratique pour laquelle un lecteur français rencontre ce sujet avant les autres.
Un nom, deux adresses
La bifurcation que prend chaque programme, et un seul des deux camps la voit
Les deux branches sont des comportements corrects. Ce qui change est la visibilité de la panne, et le camp qui a raison est celui que personne n'ouvre.
- C'est un navigateurIl ouvre les deux presque en même tempsLa RFC 8305 décrit ce rattrapage : la famille lente est abandonnée en quelques centièmes de seconde
- L'usager ne voit rien et déclare que le catalogue fonctionne
- La panne devient une affaire de machine et non de réseau
- C'est ce que faisait le poste de la banque de prêt
- C'est ping, curl ou un scriptLa première famille rendue, et aucune autreAucun rattrapage : la commande attend l'expiration, puis rend une erreur qui parle de délai
- Le message parle de temps dépassé et jamais de famille d'adresses
- Deux essais forcés rendent la panne visible en dix secondes
- C'est ce que faisaient les deux automates de prêt
Elle ne dit pas quelle famille a raison, parce que les deux l'ont. Le défaut est qu'un seul des deux chemins menait à un service à l'écoute, et que l'outil le plus consulté est celui qui le dissimule.
L'ordre des questions, et l'endroit où l'on décroche
Le blocage est exactement le moment décrit en haut de cette page : celui où les abstractions cessent d'être séparables. Quelqu'un sait définir une adresse, un enregistrement de nom et une passerelle, rencontre une panne qui n'est aucune des trois séparément et les trois à la fois, et en conclut que les vrais réseaux le dépassent. Ce qui manque n'est pas une définition de plus, c'est un ordre : établir que le câble est vivant avant de discuter des noms n'est pas de la pédanterie, c'est la seule façon de ne pas tester trois fois la même chose. Cet ordre est ce que le fonctionnement d'un réseau installe, et l'adressage est l'étage où se décide la moitié des pannes de cette page, masque et famille comprises.
Trois clusters portent ensuite les questions que celui-ci laisse ouvertes. Le matériel réseau nomme les boîtiers qu'on accuse et qui sont presque toujours innocents. Le routage et la commutation est le moment où l'on configure ces boîtiers au lieu de les nommer, et il commence à compter dès qu'un bâtiment porte deux réseaux. Le sans-fil est un problème de physique déguisé en problème de réseau : une liaison qui tient au bureau et lâche à la porte de livraison n'a rien changé à sa configuration. Et la méthode qui range tout cela en une suite de gestes est le dépannage réseau.
Ce qu'il faut ouvrir en 2026
iproute2 fournit ip et ss, il est déjà installé sur toute distribution Linux actuelle et il ne coûte rien ; il a remplacé net-tools, d'où venaient ifconfig et netstat, que montrent encore la plupart des tutoriels. resolvectl arrive avec systemd-resolved et répond à une question que nslookup ne posait pas : non pas ce qu'un serveur de noms répond, mais ce que cette machine-ci va effectivement utiliser, famille par famille. mtr a remplacé le fait de lancer un ping puis un traceroute et de comparer deux sorties de tête ; il est libre, gratuit, et présent aussi sous Windows. Pour savoir où en est le pays plutôt que sa propre ligne, le baromètre de la transition vers IPv6 publié par l'ARCEP est gratuit et se lit en dix minutes, et il a remplacé l'habitude de poser la question à son opérateur.
Quand le chemin est correct et que quelqu'un s'en sert contre vous
Une panne réseau se termine sur une phrase, et celle de Quimper tenait en deux lignes de configuration. Ce qu'aucune de ces commandes ne dit, c'est si le chemin qu'elles viennent de valider est emprunté par quelqu'un d'autre : un port en écoute est une porte, et la question de savoir qui a le droit de la pousser appartient à la cybersécurité.
Deux voisins immédiats restent utiles avant d'y aller. Les systèmes d'exploitation décident qui tient une socket et sous quel utilisateur, ce qui est la moitié de la réponse lue dans ss ; les serveurs sont l'endroit où l'on écrit la ligne de configuration qui a manqué ici. Le pilier les range dans l'ordre où ils se tiennent, sous les systèmes et les réseaux.