Suivre un flux de bout en bout

Suivre un flux de bout en bout

Un clic sur un lien déclenche une dizaine d’étapes distinctes, réparties entre le navigateur, le système d’exploitation, plusieurs serveurs de noms, des routeurs, parfois un réseau de diffusion de contenu, un mandataire inverse, et enfin l’application. Chacune peut échouer à sa manière, et chacune laisse des traces à des endroits différents. Savoir raconter ce trajet, étape par étape, est la compétence de base du diagnostic réseau comme de l’enquête de sécurité. C’est aussi le meilleur remède contre la formule « c’est le réseau », prononcée en moyenne trois minutes avant que quelqu’un ait regardé quoi que ce soit.

Explication de la marmotte

Suivre un colis depuis l’entrepôt jusqu’à la boîte aux lettres permet de savoir où il s’est perdu quand il n’arrive pas. Ce chapitre apprend à faire la même chose pour un simple clic : raconter tout le trajet d’une demande jusqu’au service lointain, pour trouver l’étape qui coince et ce que chacun peut voir en chemin.

→ Lire l’explication complète de la marmotte

Exemple conducteur : ouvrir une page HTTPS

Du lien au nom, du nom à l’adresse

Tout commence par une URL (Uniform Resource Locator), par exemple https://www.tortuetech.com/reseaux/. Elle se décompose en un schéma (https, qui implique le port 443 par défaut), un nom d’hôte (www.tortuetech.com) et un chemin (/reseaux/). Le réseau ne connaît que le nom et le port ; le chemin ne concerne que l’application.

Le navigateur doit transformer le nom en adresse IP (Internet Protocol). Il consulte d’abord son propre cache, puis demande au système d’exploitation, qui regarde le fichier hosts, son cache local, puis interroge le résolveur configuré, généralement reçu par DHCP (Dynamic Host Configuration Protocol). Ce résolveur récursif, s’il n’a pas la réponse en cache, remonte la hiérarchie du DNS (Domain Name System) jusqu’aux serveurs autoritaires du domaine. Chaque cache conserve la réponse pendant son TTL (Time To Live). Conséquence pratique : deux postes voisins peuvent obtenir des adresses différentes pour le même nom, l’un ayant gardé une ancienne réponse. Le mécanisme complet est décrit dans DNS, DHCP, NTP.

De l’adresse à la connexion

Avec l’adresse et le port, le système ouvre une connexion. Une socket est l’extrémité de cette connexion côté système ; une connexion TCP (Transmission Control Protocol) est identifiée par un quintuplet : protocole, adresse et port source, adresse et port destination. Le port source est choisi au hasard dans une plage éphémère, ce qui permet à un même poste d’ouvrir des centaines de connexions vers le même serveur.

Le premier paquet part vers la passerelle par défaut, puisque l’adresse de destination n’est pas sur le réseau local ; le poste a d’abord résolu l’adresse matérielle de cette passerelle (Résolution locale et ICMP). La box ou le pare-feu de sortie traduit souvent l’adresse privée en adresse publique (NAT, translations et publication). Le paquet traverse ensuite les routeurs du FAI (fournisseur d’accès à Internet), puis d’autres opérateurs. L’adresse obtenue n’est souvent pas celle du serveur d’origine : c’est un nœud de CDN (Content Delivery Network, réseau de diffusion de contenu), choisi parce qu’il est proche, qui termine la connexion et relaie ou sert la page depuis son cache. Derrière, un reverse proxy (mandataire inverse) répartit les requêtes entre serveurs applicatifs, et des pare-feu filtrent à chaque frontière.

La connexion TCP s’établit par la poignée de main en trois temps : SYN, SYN-ACK, ACK. Avec QUIC (normalisé par la RFC 9000) et HTTP/3, le transport passe sur UDP (User Datagram Protocol) port 443, et l’établissement du transport et du chiffrement est fusionné (QUIC et HTTP moderne).

Chiffrement, requête, réponse

Vient la négociation TLS (Transport Layer Security). Le client envoie un ClientHello qui annonce les versions et algorithmes supportés, et, dans l’extension SNI (Server Name Indication), le nom du site demandé : un même serveur héberge souvent des centaines de sites et doit savoir quel certificat présenter. Le serveur répond avec son certificat, que le navigateur vérifie : signature par une autorité reconnue, période de validité, et correspondance entre le nom demandé et les noms listés dans le certificat. Une fois la clé de session établie, le navigateur envoie la requête HTTP (HyperText Transfer Protocol), méthode, chemin, en-têtes, cookies, et reçoit une réponse : un code d’état (200, 301, 404, 503…) et un contenu. L’application, elle, a peut-être interrogé une base de données, un annuaire et trois API (Application Programming Interface) avant de répondre.

Ce qui est visible et ce qui est chiffré

Élément	Visible par le réseau local et le FAI ?
Requête DNS classique (port 53)	oui, en clair, sauf avec DoH ou DoT
Adresses IP source et destination, ports	oui, toujours
Nom du site dans le SNI	oui, sauf avec ECH (Encrypted Client Hello), encore peu déployé
Certificat du serveur	oui en TLS 1.2, chiffré en TLS 1.3
Chemin, paramètres, en-têtes, cookies, contenu	non, chiffrés
Volumes, horaires, durée des échanges	oui

DoH (DNS over HTTPS) et DoT (DNS over TLS) chiffrent les requêtes de noms, mais l’adresse IP contactée reste visible. Un observateur sur le chemin sait donc qui parle à quel service, quand et combien ; il ignore ce qui se dit. Le chiffrement protège le contenu, pas les métadonnées.

Atelier : dessiner la chaîne

Le schéma à produire tient sur une ligne : navigateur → caches et résolveur DNS → passerelle et pare-feu de sortie → FAI et transit → CDN → reverse proxy → application → base de données. Sous chaque maillon, noter ce qu’il voit (nom, adresses, contenu ou non), ce qu’il journalise et qui l’administre. Le maillon CDN, s’il termine TLS, voit le contenu en clair : c’est un tiers de confiance, souvent oublié dans les analyses de risque. Ce schéma est le chemin logique ; le chemin physique (câbles, commutateurs, fibres, liens opérateurs) peut changer d’une minute à l’autre sans que le chemin logique bouge, et inversement un changement de DNS modifie le chemin logique sans toucher un seul câble.

Observer au bon endroit

Chaque outil répond à une question précise. L’utiliser sans hypothèse produit beaucoup de sortie et peu de conclusions.

Outil	Point d’observation	Hypothèse qu’il teste
dig	poste	le nom se résout-il, vers quelle adresse, avec quel TTL ?
curl -v	poste	connexion, TLS et HTTP réussissent-ils, où échoue la chaîne ?
ss -tn	poste ou serveur	une connexion existe-t-elle, dans quel état ?
capture (tcpdump, Wireshark)	poste ou point du réseau	les paquets partent-ils, reviennent-ils, qui coupe ?
journal du reverse proxy	côté service	la requête est-elle arrivée, quel code a été renvoyé ?
journal applicatif	côté service	quelle erreur interne explique la réponse ?

L’observation locale (sur le poste) dit ce que le client croit ; l’observation réseau (capture sur un port miroir, journaux du pare-feu) dit ce qui a réellement circulé ; l’observation côté service dit ce que le serveur a reçu et décidé. Une requête visible localement mais absente des journaux du serveur s’est perdue entre les deux : c’est là qu’il faut capturer. Les techniques de capture sont détaillées dans Captures, observabilité et diagnostic.

Atelier : tracer une requête HTTPS

dig +noall +answer www.tortuetech.com A
curl -v -o /dev/null https://www.tortuetech.com/
ss -tn state established '( dport = :443 )'

dig affiche la ou les adresses et le TTL restant ; si la réponse diffère de celle d’un autre poste, un cache ou un résolveur différent est en cause. curl -v raconte la suite dans l’ordre : Trying 203.0.113.10:443, puis Connected to, la version TLS négociée, le sujet du certificat, le résultat de la vérification, la requête envoyée et la ligne HTTP/2 200. ss liste les connexions établies vers le port 443 avec leurs quintuplets. En parallèle, Wireshark avec le filtre tls.handshake.type == 1 montre les ClientHello et le SNI en clair ; le filtre dns montre les requêtes de noms. Le contenu HTTP, lui, reste illisible : ce qui est exactement le but.

Atelier : diagnostiquer trois pannes

DNS absent. curl répond Could not resolve host. Aucune connexion n’a été tentée, inutile de regarder le pare-feu. dig renvoie NXDOMAIN (le nom n’existe pas) ou SERVFAIL (le résolveur n’a pas pu obtenir de réponse, par exemple à cause d’une validation DNSSEC (DNS Security Extensions) en échec ou d’un serveur autoritaire injoignable). Comparer avec dig @9.9.9.9 distingue un problème du résolveur local d’un problème de la zone.

Port filtré. curl affiche Trying 203.0.113.10:443 puis attend jusqu’au délai d’expiration. La capture montre des SYN répétés sans réponse : un équipement jette les paquets en silence. Si la réponse est immédiate, Connection refused, un paquet RST est revenu : soit rien n’écoute sur ce port, soit un pare-feu rejette activement. Silence et refus ne désignent pas le même coupable.

Certificat incorrect. La connexion TCP réussit, mais curl échoue avec l’erreur 60 et un message comme no alternative certificate subject name matches target host name, ou un certificat expiré, ou une autorité inconnue. Le réseau fonctionne ; c’est l’identité du serveur qui est en cause. Une erreur TLS survient avant toute requête HTTP : il n’y a donc ni code 404 ni code 500 à chercher. Une erreur HTTP (403, 502, 503) prouve au contraire que TLS a réussi et que quelqu’un, serveur ou intermédiaire, a répondu. Le guide Diagnostiquer les erreurs de validation TLS détaille les cas.

Un 502 ou un 504 renvoyé par le reverse proxy illustre la différence entre connexion établie et service fonctionnel : la connexion du client a parfaitement abouti, c’est l’application derrière qui ne répond pas.

Lecture sécurité du chemin

Quatre manipulations se dissimulent derrière des symptômes de panne. L’interception place un intermédiaire au milieu : un proxy d’entreprise qui inspecte TLS présente son propre certificat, signé par une autorité interne installée sur les postes ; le même mécanisme, sans autorité installée, déclenche une alerte de certificat que l’utilisateur ne devrait jamais contourner. L’altération modifie le contenu en transit, possible uniquement sur les échanges non chiffrés ou après une interception. Le blocage se traduit par un nom qui ne se résout plus, un port qui expire ou une connexion coupée par un RST injecté. La redirection envoie ailleurs : réponse DNS falsifiée, portail captif, règle de proxy.

Les indices se croisent. La réponse DNS dit où le client est allé ; le SNI dit quel site il a demandé ; le certificat reçu dit qui a répondu ; les journaux du serveur disent si la requête est arrivée. Un SNI correct suivi d’un certificat émis par une autorité inattendue signe une interception, légitime ou non. Une adresse DNS hors des plages habituelles du service signe une redirection. Désactiver la vérification du certificat pour « débloquer » une application revient à supprimer l’alarme plutôt que d’éteindre l’incendie.

Le chiffrement n’est pas l’anonymat. Le FAI voit les adresses contactées, souvent le SNI et les requêtes DNS ; le CDN et le serveur voient l’adresse source et tout le contenu. Masquer la source demande d’autres mécanismes, VPN (Virtual Private Network) ou réseau d’anonymisation, qui déplacent la confiance vers un autre opérateur plus qu’ils ne la suppriment.

Pièges classiques

Lire une capture sans scénario noie l’analyste sous des milliers de paquets. Il faut d’abord formuler l’hypothèse (« le SYN part-il ? ») et filtrer en conséquence.

Confondre erreur TLS et erreur HTTP envoie l’équipe chercher dans les journaux applicatifs une requête qui n’est jamais arrivée.

Oublier caches, proxys, CDN et autres middleboxes (équipements intermédiaires qui modifient ou terminent le trafic) fait diagnostiquer le mauvais serveur : la page vue par l’utilisateur vient peut-être d’un cache vieux de six heures.

À ne pas confondre

Chemin logique et chemin physique : le premier enchaîne des services, le second des câbles. Une panne de l’un se lit rarement avec les outils de l’autre.

Connexion établie et service fonctionnel : un port qui accepte la connexion prouve qu’un processus écoute, pas qu’il sait répondre.

Chiffrement et anonymat : le contenu est caché, l’échange ne l’est pas.

🐝 Ce qui arrive si on s’en passe

Sans capacité à reconstituer un flux de bout en bout, une interception ou une redirection se confond avec une panne ordinaire : une réponse de noms falsifiée, un intermédiaire qui présente son propre certificat ou un mandataire qui réécrit le contenu produisent des symptômes que l’équipe corrige par contournement, en désactivant par exemple la vérification du certificat, sans jamais nommer la cause. Faute de savoir quel point d’observation voit quoi, les journaux utiles ne sont ni conservés ni corrélés, et l’enquête après incident découvre qu’aucune machine n’a enregistré l’étape où le trafic a dévié. La conviction que le chiffrement suffit laisse enfin fuir la liste des services consultés, lisible dans les noms résolus et annoncés en clair.

🦫 Explication de la marmotte 🍫

Ouvrir une page sécurisée déclenche une suite d’étapes. D’abord, le navigateur doit transformer le nom du site en adresse numérique : il consulte ses mémoires locales, puis interroge le système de noms de domaine, qui associe chaque nom à une adresse. Ensuite, il ouvre une connexion vers cette adresse et vers un numéro de port, qui désigne le service visé sur la machine. Les données traversent la passerelle locale, les routeurs du fournisseur d’accès, parfois un réseau de distribution de contenu ou un serveur intermédiaire placé devant l’application, et des pare-feu. Une fois la connexion établie, les deux côtés mettent en place le chiffrement ; le serveur présente un certificat qui prouve son nom. Enfin, le navigateur envoie sa requête et reçoit la réponse de l’application. Chaque étape peut échouer à sa manière : nom introuvable, port bloqué, certificat incorrect, erreur renvoyée par l’application. Une connexion réussie ne prouve pas que le service fonctionne. Pour diagnostiquer, on part d’une hypothèse, puis on observe au bon endroit : sur le poste, sur le réseau ou dans les journaux du serveur, avec un outil adapté à chaque question. Côté sécurité, le chiffrement protège le contenu mais laisse visibles certaines informations, comme l’adresse contactée ou le nom du site demandé. Chiffrer ne rend donc pas anonyme.

À lire aussi

• DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défenseComparaison de DNSSEC, DoT, DoH, DoQ et ODoH, ce que chacun protège et contre qui, ce que la résolution chiffrée retire à la détection et comment la défense reprend la main.
• UDP, TCP et comportements de transportComprendre les transports classiques, leurs états, timeouts, performance et risques de sécurité.
• Couches, normes et vocabulaire de paquetsConstruire le vocabulaire nécessaire pour lire une communication réseau : couche, protocole, encapsulation, trame, paquet, segment, datagramme, message et plans réseau.
• La poignée de main TLS 1.3 en une pageClientHello, ServerHello, dérivation des clés, certificat chiffré et Finished : la poignée de main TLS 1.3 (RFC 8446) animée en six étapes, avec le 0-RTT et ses risques de rejeu.

Pages voisines

La citent

• Comprendre pourquoi les systèmes communiquent
• Décision de chemin, routes statiques et routage système

Suivre un flux de bout en bout

Elle cite

• DNS, DHCP, NTP : services d'infrastructure réseau
• NAT, translations et publication de services
• QUIC, HTTP moderne, TLS et proxys applicatifs
• Résolution locale, ICMP, MTU et multicast
• Captures, observabilité et diagnostic multi-couche
• Ce que le bout en bout laisse voir
• Diagnostiquer les erreurs de validation TLS en production
• Gérer les risques tiers et la chaîne logicielle