Méthode de diagnostic réseau couche par couche

Principe

Un incident « le service ne répond pas » se diagnostique du bas vers le haut (ou par dichotomie à partir de la couche 3). À chaque étape, notez l'hypothèse, la commande et le résultat : c'est ce qui rendra le post-mortem exploitable.

1. Interface et lien (L1/L2)

ip -br link            # UP/DOWN
ip -s link show eth0   # erreurs, drops
ethtool eth0           # vitesse/duplex (serveurs physiques)

2. Adressage et routage (L3)

ip -br addr
ip route get 10.20.0.15     # quelle route, quelle interface, quelle source
ping -c3 <passerelle>; ping -c3 10.20.0.15
tracepath 10.20.0.15

Un ping qui échoue ne prouve rien si l'ICMP est filtré : passez directement au test TCP.

3. Résolution de noms

getent hosts api.interne       # ce que voit réellement l'application (nsswitch)
dig +short api.interne @10.0.0.53
cat /etc/resolv.conf /etc/hosts

Piège fréquent : une entrée obsolète dans /etc/hosts, prioritaire sur le DNS.

4. Transport (L4)

nc -vz api.interne 8443          # port ouvert ?
ss -tlnp | grep 8443             # côté serveur : qui écoute, sur quelle adresse ?

• Connection refused → la machine répond mais rien n'écoute sur ce port (ou écoute sur 127.0.0.1).
• Timeout → filtrage (pare-feu, security group) ou routage retour.

5. Filtrage

sudo nft list ruleset
sudo iptables -S

Vérifiez les deux sens et les équipements intermédiaires : la matrice de flux est la référence.

6. Application (L7)

curl -sv https://api.interne:8443/health
openssl s_client -connect api.interne:8443 -servername api.interne

Checklist de clôture

• Cause racine identifiée et corrigée durablement (configuration gérée, pas une modification manuelle).
• Supervision ajoutée pour détecter la récidive.
• Fiche de troubleshooting mise à jour.