Captures, observabilité et diagnostic multi-couche

Captures, observabilité et diagnostic multi-couche

« Internet ne marche pas » n’est pas un diagnostic, c’est un état d’âme. Entre le câble et l’application s’empilent une dizaine de couches, chacune capable de produire le même symptôme vu de l’utilisateur. Ce chapitre propose une méthode pour les parcourir dans l’ordre, les outils de terrain qui répondent à chaque question, puis les outils d’investigation qui servent autant à dépanner qu’à repérer un comportement suspect.

Explication de la marmotte

Quand une voiture refuse de démarrer, un bon garagiste ne change pas les pièces au hasard : il vérifie d’abord la batterie, puis le démarreur, puis l’arrivée d’essence, en notant ce qu’il a écarté. Ce chapitre applique cette patience méthodique aux pannes et aux comportements suspects d’un réseau informatique.

→ Lire l’explication complète de la marmotte

Diagnostiquer avec méthode

Du symptôme à l’hypothèse

Un dépannage commence par un symptôme précis : qui est touché, depuis quand, vers quelle destination, avec quel message. « Le poste 12 n’ouvre plus l’intranet depuis 9 h, les autres sites web fonctionnent » élimine déjà la moitié des causes. On formule alors une hypothèse testable, on choisit le test qui la confirme ou l’infirme le plus vite, et on note le résultat. Le symptôme n’est pas la cause racine : un délai d’expiration applicatif peut venir d’un câble défectueux, d’une route manquante ou d’un certificat expiré.

Parcourir les couches dans l’ordre

Couche	Question	Test typique
Physique	le signal passe-t-il ?	voyant de lien, testeur de câble, puissance optique
Liaison	le voisin est-il vu ?	table ARP ou ND, compteurs d’erreurs de l’interface
IP	l’adresse et le masque sont-ils corrects ?	ip address, ipconfig /all
Routage	existe-t-il un chemin ?	ip route get 198.51.100.20, traceroute
Transport	le port répond-il ?	nc -vz hôte 443, Test-NetConnection hôte -Port 443
DNS	le nom se résout-il correctement ?	dig nom, nslookup nom
TLS (Transport Layer Security)	la négociation aboutit-elle ?	openssl s_client -connect hôte:443 -servername nom
Application	le service répond-il bien ?	curl -v, journaux du serveur

Chaque couche dépend de celles du dessous ; un test réussi en haut valide implicitement le bas. Il est donc souvent rentable de tester d’abord au milieu, par exemple un ping vers l’adresse IP (Internet Protocol) de la passerelle, puis de monter ou descendre selon le résultat.

Documenter ce qui est exclu

Le carnet de diagnostic note chaque test, son résultat et ce qu’il exclut : « 9 h 40, ping 10.0.1.1 OK, la couche physique et l’adressage local sont hors de cause ». Ce journal évite de refaire trois fois le même test, permet de passer le relais à un collègue et devient la chronologie de l’incident si l’affaire tourne à l’investigation de sécurité.

Outils de terrain

Câble, fibre et carte

Le testeur de câble vérifie la continuité et le câblage des huit conducteurs d’une paire torsadée ; le réflectomètre (TDR, Time Domain Reflectometer) localise une coupure en mesurant le temps de retour d’une impulsion, et sa version optique, l’OTDR, fait de même sur une fibre. Le multimètre contrôle une alimentation, par exemple la tension PoE (Power over Ethernet), autour de 48 V nominaux. Sur une fibre, un photomètre mesure la puissance reçue en dBm et la compare à la sensibilité de l’optique ; un connecteur sale reste la première cause de liens optiques capricieux, et le nettoyer coûte moins cher que de remplacer l’émetteur.

Côté Ethernet, ethtool eth0 affiche vitesse et mode duplex, et ip -s link les compteurs d’erreurs : des erreurs CRC (Cyclic Redundancy Check) en hausse trahissent un câble ou un port abîmé, des collisions tardives un désaccord de duplex. Une adresse MAC (Media Access Control) en double, après un clonage de machine virtuelle par exemple, provoque des coupures intermittentes qui ressemblent à tout sauf à leur cause. Le sujet est approfondi dans Ethernet, trames et commutation locale.

Commandes système

Besoin	Linux	Windows
Adresses	ip address	ipconfig /all
Routes	ip route	route print
Voisins (ARP, IPv4 ; ND, IPv6)	ip neigh	arp -a, Get-NetNeighbor
Connexions et ports à l’écoute	ss -tulpn	netstat -ano
Résolution DNS	dig, nslookup	nslookup, Resolve-DnsName
Chemin	traceroute, mtr	tracert, pathping
Noms NetBIOS	nmblookup -A	nbtstat -A adresse

L’ARP (Address Resolution Protocol) associe une adresse IPv4 à une adresse MAC ; en IPv6, c’est ND (Neighbor Discovery) qui s’en charge (voir Résolution locale, ICMP, MTU et multicast). netstat, historique, est remplacé sous Linux par ss, plus rapide. Sous Windows, la suite Sysinternals de Microsoft complète l’outillage : TCPView montre quelle application tient quelle connexion, Process Monitor ce qu’un processus lit et écrit.

Lire sans surinterpréter

Un ping sans réponse ne prouve pas qu’un hôte est éteint : ICMP (Internet Control Message Protocol) est souvent filtré. Un traceroute plein d’étoiles signifie que certains routeurs ne répondent pas, pas qu’ils ne transmettent pas ; seule compte la dernière ligne. Un dig qui répond depuis le cache d’un résolveur ne dit rien du serveur autoritaire, qu’il faut interroger directement (dig @ns1.exemple.org exemple.org). Et un port « ouvert » vu par nc prouve qu’un service accepte la connexion, pas qu’il fonctionne.

Captures paquet

tcpdump et Wireshark enregistrent les paquets réels, ce qui met fin aux débats. Capturer une résolution DNS suivie d’une connexion web :

tcpdump -i eth0 -nn -w diag.pcap 'port 53 or host 203.0.113.50'

Dans Wireshark, le filtre dns montre la question et la réponse avec leur délai ; tcp.flags.syn == 1 isole les poignées de main. Un échange sain se lit SYN, SYN-ACK, ACK ; un SYN sans réponse, répété après 1, 3 puis 7 secondes environ selon le système, désigne un filtrage silencieux ; un RST (reset) immédiat, un port fermé ou un pare-feu qui refuse franchement. Une capture n’est pas un journal applicatif : elle montre ce qui a circulé, pas ce que l’application en a compris, et le contenu chiffré par TLS y reste illisible sans les clés de session.

Combiner journaux réseau et applicatifs

Le journal du serveur web dit « 502 à 10:14:03 », la capture montre un RST du serveur applicatif à 10:14:03, le journal du pare-feu montre une règle de sortie refusée à la même seconde. C’est la corrélation qui donne la cause, et elle suppose des horloges synchronisées (voir DNS, DHCP, NTP : services d’infrastructure réseau).

Investigation avancée

Flux, sondes et noyau

NetFlow, format de Cisco dont la version 9 est décrite par le RFC (Request for Comments) 3954, et IPFIX (IP Flow Information Export, RFC 7011), son successeur normalisé, résument le trafic en enregistrements de flux : adresses, ports, protocole, volume, durée. Ils ne contiennent pas les données mais suffisent à repérer qui parle à qui et combien. Zeek analyse le trafic et produit des journaux structurés par protocole (conn.log, dns.log, http.log, ssl.log) ; Suricata applique des signatures et génère des alertes, tout en produisant lui aussi des journaux de protocole. Nmap inventorie activement : nmap -sS -p 1-1024 10.0.5.0/24 cherche les ports ouverts, et l’option -Pn évite de conclure qu’un hôte est absent parce qu’il ne répond pas au ping. eBPF (extended Berkeley Packet Filter) exécute des programmes vérifiés dans le noyau Linux pour observer connexions et latences au niveau des processus, sans module noyau ni modification des applications (voir eBPF pour observer et bloquer dans le noyau Linux).

Ce qui doit attirer l’œil

Un balayage de ports se voit dans les flux : une source, des centaines de ports ou d’hôtes, des connexions très courtes. Un DNS anormal se voit dans dns.log : des noms longs et aléatoires vers un même domaine (tunnel ou algorithme de génération de domaines), un volume inhabituel de requêtes TXT, des requêtes vers des résolveurs externes au lieu des résolveurs internes. Un flux inattendu : un serveur de base de données qui ouvre des connexions vers Internet. Une asymétrie : un flux sortant volumineux depuis un poste qui ne fait d’habitude que consulter. Les menaces correspondantes sont détaillées dans Menaces réseau, détection et réponse opérationnelle.

Encadrer la géolocalisation IP

Le WHOIS et son successeur RDAP (Registration Data Access Protocol) disent à quelle organisation une adresse est attribuée. Les bases de géolocalisation estiment un pays avec une fiabilité correcte, une ville beaucoup moins. Le VPN (Virtual Private Network), le relais, l’anycast et la traduction d’adresses chez les opérateurs mobiles faussent l’estimation, et une attaque « venue de » tel pays vient surtout d’une machine qui s’y trouve, louée ou compromise. Une géolocalisation est un indice, jamais une attribution.

Le cadre légal

Capturer le trafic d’autrui touche au secret des correspondances, et balayer un système sans autorisation peut relever de l’accès ou de la tentative d’accès frauduleux, réprimés en France par les articles 323-1 et suivants du Code pénal. Sur un réseau d’entreprise, les captures se font dans le cadre d’une mission définie, avec information des utilisateurs prévue par la charte ; sur un système tiers, avec une autorisation écrite. Scanner n’est pas exploiter, mais le juge comme l’administrateur d’en face n’ont pas toujours le temps de faire la nuance.

Exemples et ateliers

La panne Internet en étapes. Un poste ne charge aucun site. ip address : adresse 169.254.x.x, autoattribuée, donc aucun bail DHCP (Dynamic Host Configuration Protocol). Le voyant du port est éteint : câble débranché sous le bureau. Rebranché, le poste obtient 10.0.1.42/24. ping 10.0.1.1 répond, ping 1.1.1.1 répond, mais curl https://exemple.org échoue sur « Could not resolve host » : dig exemple.org expire, dig @1.1.1.1 exemple.org répond. Le résolveur interne est en cause, pas le réseau. Trois étapes, deux pannes, aucune réinstallation.

Capturer poignée de main et DNS. Lancer tcpdump -nn -i eth0 'port 53 or port 443', puis curl -I https://exemple.org. Repérer la requête A? et sa réponse, puis le SYN, le SYN-ACK et l’ACK vers l’adresse obtenue, puis le ClientHello TLS. Mesurer l’écart entre la question DNS et le SYN : c’est le temps de résolution vu par l’application.

Lire une alerte Suricata. Dans eve.json :

{"timestamp":"2026-03-12T10:14:03.512+0100","event_type":"alert",
 "src_ip":"10.0.5.23","src_port":51544,"dest_ip":"203.0.113.80","dest_port":4444,
 "proto":"TCP","alert":{"action":"allowed","signature_id":1000001,
 "signature":"LOCAL sortie vers port 4444 inhabituel","severity":2}}

L’alerte dit qu’un poste interne a ouvert une connexion vers un port souvent utilisé par des outils d’accès à distance, et que rien ne l’a bloquée (allowed). Elle ne dit pas que le poste est compromis. Étapes suivantes : conn.log pour la durée et le volume, dns.log pour le nom résolu juste avant, le journal du poste pour le processus à l’origine.

Pièges classiques

Lancer des outils au hasard produit beaucoup de sorties et peu de conclusions. Conclure à un hôte éteint sur la seule absence de réponse ICMP fait sortir de l’inventaire une machine bien vivante. Se fier à une géolocalisation pour accuser un pays ou un fournisseur. Et capturer sans filtre sur un lien chargé remplit un disque en quelques minutes, en perdant justement les paquets intéressants.

🐝 Ce qui arrive si on s’en passe

Sans méthode ni outils d’observation, une panne et une intrusion produisent le même symptôme, une connexion qui échoue ou un flux qui ralentit, et rien ne permet de les distinguer. Un balayage de ports, une résolution de noms vers un domaine inhabituel ou un flux sortant inattendu passent alors pour du bruit réseau, faute de référence à laquelle les comparer. L’absence de réponse aux messages de test fait déclarer éteinte une machine qui se contente de filtrer, et elle sort de l’inventaire en restant allumée. Après incident, sans capture ni journal de flux conservé, la chronologie se reconstitue par déduction, et une géolocalisation d’adresse prise au pied de la lettre désigne volontiers le mauvais coupable.

🦫 Explication de la marmotte 🍫

Un réseau informatique fonctionne par couches successives : le câble ou la fibre qui transporte le signal, la liaison entre deux appareils voisins, l’adressage qui donne un numéro à chaque machine, le routage qui choisit le chemin, le transport qui découpe et remet les données, la traduction des noms en adresses, le chiffrement, puis l’application elle-même. Une panne se situe dans l’une de ces couches, et chacune dépend de celles du dessous. La méthode consiste à partir d’un symptôme précis, à formuler une hypothèse, puis à tester les couches dans l’ordre en notant celles qui fonctionnent. Des testeurs vérifient les câbles, des commandes du système affichent l’adresse de la machine, ses routes et ses connexions ouvertes, d’autres interrogent l’annuaire des noms ou mesurent si une machine distante répond. Une absence de réponse ne prouve pas qu’une machine est éteinte : elle peut simplement filtrer ces messages de test. Pour aller plus loin, une capture enregistre tous les paquets qui passent sur une interface, afin de lire exactement ce qui a été envoyé et reçu. Des outils de surveillance résument les échanges en flux, repèrent les balayages de ports, les demandes de noms anormales ou les trafics inattendus, et déclenchent des alertes. La position géographique déduite d’une adresse reste approximative. Enfin, capturer ou balayer un réseau obéit à des règles légales, à connaître avant d’agir.

À lire aussi

• Suivre un flux de bout en boutApprendre à raconter un échange complet depuis une action utilisateur jusqu’au service distant, en distinguant nom, adresse, chemin, transport, chiffrement et réponse applicative.
• Nmap pour cartographier un réseau, des hôtes aux services exposésFiche de l'outil nmap, de la découverte d'hôtes à la détection de services, avec ce qu'un scan révèle, ce qu'un pare-feu fausse, comment le défenseur s'en sert et comment un scan se détecte.
• UDP, TCP et comportements de transportComprendre les transports classiques, leurs états, timeouts, performance et risques de sécurité.
• Wireshark, capturer et lire des trames réseau avec filtres et TLSFiche d'outil Wireshark, de la capture de trames à la lecture couche par couche, avec filtres de capture et d'affichage, tshark, déchiffrement TLS de son propre trafic, limites et cadre légal.

Pages voisines

La citent

• Couches, normes et vocabulaire de paquets
• DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défense
• Géographie d'internet, câbles sous-marins et points d'atterrissement
• Gestion réseau, supervision et référentiels d’exploitation
• Google Street View Wi-Spy 2010 : trames Wi-Fi en clair et droit
• Performance, QoS, capacité et sobriété énergétique

Captures, observabilité et diagnostic multi-couche

Elle cite

• Comment attribuer techniquement une cyberattaque
• Configurer Suricata sur un segment réseau critique
• DNS, DHCP, NTP : services d'infrastructure réseau
• EBPF pour observer et bloquer dans le noyau Linux
• Ethernet, trames et commutation locale
• Menaces réseau, détection et réponse opérationnelle