Dépannage réseau Bash : guide pratique couche par couche

Introduction

Lorsqu'un service ne parvient pas à atteindre un point de terminaison, la cause relève généralement de l'une de cinq catégories : la résolution de noms, l'accessibilité, le routage, le filtrage ou des problèmes de la couche applicative tels que la configuration TLS et des proxys. Ce guide montre comment diagnostiquer chaque classe de problème en utilisant Bash sur des systèmes Linux. Il privilégie des étapes sûres et vérifiables, exécutables sur des postes de développement comme sur des serveurs en production, sans deviner ni risquer des modifications dangereuses.

Vous apprendrez à :

• Faire l'inventaire de votre environnement et de l'état réseau au préalable
• Exécuter des vérifications rapides, en lecture seule, qui localisent la panne
• Inspecter DNS, ports, routes, pare-feu, proxys et TLS
• Interpréter les résultats attendus et distinguer les faux positifs
• Revenir proprement de modifications mineures et temporaires
• Créer une liste de contrôle opérationnelle reproductible

Tous les exemples utilisent des noms d'hôtes, domaines et adresses factices. Remplacez-les par les valeurs de votre environnement.

Inventaire des versions et de l'environnement

Avant de changer quoi que ce soit, capturez l'existant. Cela accélère l'analyse de cause racine et crée une base de référence pour la comparaison.

Commandes pour instantané des versions système et d'outillage :

# OS et noyau
cat /etc/os-release
uname -a

# Bash et outils réseau de base
bash --version | head -n1
ip -V 2>/dev/null
ss -V 2>/dev/null || netstat -V 2>/dev/null
dig -v 2>/dev/null || host -v 2>/dev/null
command -v resolvectl >/dev/null && resolvectl --version

# La synchronisation d'heure peut affecter la validation TLS
command -v timedatectl >/dev/null && timedatectl

Instantané de l'état réseau courant (aucune modification) :

# Adresses, liaisons et routes
ip addr show
ip link show
ip route show

# Route par défaut et décision de routage pour une cible
ip route get 203.0.113.10

# Vue DNS
cat /etc/resolv.conf
command -v resolvectl >/dev/null && resolvectl status

# Ordre du commutateur de service de noms
getent -E '^[[:space:]]*hosts:' /etc/nsswitch.conf || echo 'entrée hosts nsswitch.conf introuvable'

Collecte du contexte des services :

# Écouteurs locaux (sudo requis pour les noms de processus sur de nombreux systèmes)
sudo ss -tulpn

# Proxys d'environnement
env | grep -iE '^(http|https|no)_proxy='

Stockez les instantanés dans un répertoire horodaté pour pouvoir les différencier plus tard :

TS=$(date +%Y%m%d-%H%M%S); mkdir -p net-snap-$TS; cd net-snap-$TS
cp /etc/resolv.conf . 2>/dev/null || true
{ ip addr; ip route; ip link; } > ip-state.txt
{ ss -tulpn || netstat -tulpn; } > sockets.txt 2>/dev/null
{ resolvectl status || true; } > resolve-status.txt 2>/dev/null
{ env | grep -iE '^(http|https|no)_proxy=' || true; } > proxies.txt

Chemin de configuration sûr

Adoptez une approche ciblée, réversible et observable :

• Périmètre : choisissez un nom d'hôte en échec et un port à investiguer, par exemple api.internal.example.com sur TCP 443. Ne modifiez pas de réglages globaux avant de pouvoir reproduire et localiser la panne.
• Sauvegardes : avant d'éditer des fichiers comme /etc/hosts ou /etc/nsswitch.conf, créez des sauvegardes datées : sudo cp /etc/hosts /etc/hosts.bak.$(date +%s).
• Lecture seule d'abord : privilégiez les commandes qui observent l'état (ip, ss, dig, curl -v) plutôt que celles qui le modifient.
• Modifications temporaires et minimales seulement si nécessaire : si vous devez ajuster une règle ou un fichier pour tester, notez immédiatement la commande d'annulation.
• Validez localement : prouvez que chaque étape a fonctionné en capturant la sortie et en la comparant à votre base de référence.

Cela garde le dépannage mesurable et facile à annuler en cas de problème.

Tests de connectivité de base

Ces vérifications rapides indiquent où concentrer les efforts ensuite.

# 1) Pouvons-nous atteindre l'IP cible du tout ?
ping -c 2 203.0.113.10 || echo 'ICMP peut être bloqué ; continuer avec les tests TCP'

# 2) Pouvons-nous résoudre le nom d'hôte en IP ?
getent hosts api.internal.example.com || true

# 3) Résolution via le(s) résolveur(s) configuré(s)
dig +timeout=2 +tries=1 api.internal.example.com A

# 4) Forcer IPv6 et IPv4 pour voir les problèmes spécifiques à une famille
dig +timeout=2 +tries=1 api.internal.example.com AAAA

# 5) Si vous avez une IP attendue, testez l'accessibilité TCP
nc -vz 203.0.113.10 443

# 6) Testez la couche applicative rapidement (sans télécharger le corps)
curl -I -sS https://api.internal.example.com || curl -vkI https://api.internal.example.com

Interprétation des résultats :

• Le nom résout mais TCP échoue : concentrez-vous sur le routage, le pare-feu ou la disponibilité du service cible.
• Le nom ne résout pas : concentrez-vous sur la configuration DNS et les sources.
• IPv4 fonctionne mais IPv6 échoue (ou l'inverse) : investiguez les chemins dual-stack, les enregistrements AAAA et le pare-feu par famille.
• La poignée de main TCP fonctionne mais HTTP/TLS échoue : inspectez les variables d'environnement proxy, le SNI et les chaînes de certificats.

Référence rapide : tests de première ligne

Dépannage DNS

Validez où votre système obtient les réponses et dans quel ordre.

1. Inspectez les sources de résolution et leur ordre :

cat /etc/resolv.conf
grep -E '^[[:space:]]*hosts:' /etc/nsswitch.conf
command -v resolvectl >/dev/null && resolvectl status

• Si /etc/resolv.conf pointe vers 127.0.0.53, votre système utilise systemd-resolved. Utilisez resolvectl pour voir les serveurs DNS amont réels.
• nsswitch.conf montre généralement hosts: files dns. Cela signifie que /etc/hosts est vérifié avant le DNS.

1. Comparez les réponses de chaque source :

# Vue NSS
getent hosts api.internal.example.com

# Résolveur direct (défaut courant)
dig +nocmd api.internal.example.com A +noall +answer

# Interroger un serveur DNS spécifique (ex. résolveur d'entreprise)
dig @192.0.2.53 api.internal.example.com A +noall +answer

# Vérifier l'asymétrie AAAA vs A
dig api.internal.example.com AAAA +short; dig api.internal.example.com A +short

1. Suivez les chaînes CNAME et les TTL :

dig api.internal.example.com +trace +nodnssec | sed -n '1,80p'

1. Videz les caches (effet temporaire, lecture seule) :

# Sur les systèmes systemd-resolved
sudo resolvectl flush-caches 2>/dev/null || sudo systemd-resolve --flush-caches 2>/dev/null || true

1. Épinglez temporairement un hôte pour un test :

# Ajoutez une seule ligne de test, puis supprimez-la après
sudo cp /etc/hosts /etc/hosts.bak.$(date +%s)
echo '203.0.113.10 api.internal.example.com' | sudo tee -a /etc/hosts
getent hosts api.internal.example.com
# Annulez quand c'est fait : restaurez la sauvegarde ou supprimez la ligne

Signaux courants :

• SERVFAIL ou REFUSED : problème DNS amont ou type de requête bloqué.
• NXDOMAIN pour A mais AAAA valide (ou l'inverse) : incompatibilité dual-stack.
• getent diffère de dig : l'ordre /etc/hosts ou nsswitch.conf affecte les résultats.

Sources de résolution de noms et où vérifier

Ports et services

Découvrez si quelque chose écoute localement, si vous pouvez atteindre un port distant et ce que l'application répond.

Écouteurs locaux :

# Note : sudo requis pour les détails de processus sur de nombreux systèmes
sudo ss -tulpn | sed -n '1,50p'

Champs clés à lire :

• Adresse locale : Port montre les interfaces liées (0.0.0.0 signifie toutes IPv4, :: signifie toutes IPv6).
• État LISTEN confirme que le serveur attend des connexions.

Accessibilité distante et bannière du serveur :

# Poignée de main TCP seulement (rapide)
nc -vz api.internal.example.com 443

# En-têtes HTTP(S) sans corps
curl -I -sS https://api.internal.example.com || curl -vkI https://api.internal.example.com

# Affiche la poignée de main TLS, le SNI et la chaîne de certificats
openssl s_client -connect api.internal.example.com:443 -servername api.internal.example.com -brief -showcerts </dev/null

Interprétation des résultats :

• Connexion refusée : l'hôte cible est accessible mais aucun processus n'écoute sur ce port.
• Délai de connexion dépassé : le routage ou le pare-feu bloque probablement ; investiguez les sauts et le filtrage.
• TLS : CA inconnue ou inadéquation de nom d'hôte indique des problèmes de certificat ou de SNI.

Routage et MTU

Identifiez le chemin et détectez les problèmes de fragmentation causant des échecs intermittents.

Quelle route est choisie pour une cible :

ip route get api.internal.example.com

Tracez le chemin et détectez où les paquets s'arrêtent :

# Traceroute basé TCP passe souvent où ICMP est filtré
sudo traceroute -T -p 443 api.internal.example.com 2>/dev/null || traceroute api.internal.example.com

Détectez les trous noirs MTU :

# Test avec DF (ne pas fragmenter) et tailles croissantes sur IPv4
ping -M do -s 1472 -c 2 api.internal.example.com  # 1472 + 28 en-tête IP/ICMP ~= 1500 MTU
ping -M do -s 8972 -c 2 api.internal.example.com  # Pour chemins jumbo, si attendus

Signaux :

• Routage asymétrique : les chemins sortant et entrant diffèrent, souvent visible dans traceroute vs journaux serveur.
• Problèmes PMTU : les petites requêtes fonctionnent, les grosses poignées de main TLS bloquent ; les pings DF échouent pour des tailles au-dessus d'un seuil.

Vérifications pare-feu

Effectuez d'abord des inspections en lecture seule. Évitez de changer les politiques pendant le diagnostic sauf fenêtre de maintenance convenue et plan de retour arrière.

Listez les règles sans risque sur les piles courantes :

# nftables (moderne)
sudo nft list ruleset

# iptables (hérité ou couche de compatibilité)
sudo iptables -S; sudo iptables -L -n -v

# UFW (interface vers iptables)
sudo ufw status verbose

# firewalld (zones et services)
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

Examinez les politiques par défaut et les compteurs :

• Politiques DROP/REJECT avec compteurs de paquets croissants indiquent généralement un filtrage à cette chaîne.
• Règles DNAT/SNAT peuvent rediriger le trafic inattendu ; confirmez la destination après NAT.

Si une règle d'autorisation temporaire est nécessaire, notez d'abord la commande inverse exacte. Exemple avec iptables :

# Planifiez l'ajout et la suppression avant d'exécuter l'un ou l'autre :
# Pour ajouter (exemple) : sudo iptables -I INPUT -p tcp --dport 443 -s 198.51.100.0/24 -j ACCEPT
# Pour supprimer (retour arrière) : sudo iptables -D INPUT -p tcp --dport 443 -s 198.51.100.0/24 -j ACCEPT

Correspondance des outils pare-feu

Proxys et TLS

Les proxys silencieux et les problèmes de certificats se déguisent souvent en pannes réseau.

Détectez et interprétez les variables proxy :

env | grep -iE '^(http|https|no)_proxy='
# Exemple de nettoyage pour test (shell seulement, pas global)
unset http_proxy https_proxy no_proxy HTTP_PROXY HTTPS_PROXY NO_PROXY

Sondez avec et sans variables proxy pour confirmer le changement de comportement. Si un proxy d'entreprise est requis, testez-le explicitement :

HTTPS_PROXY=http://proxy.internal.example.com:3128 curl -I -sS https://api.internal.example.com

Vérifiez les poignées de main TLS et le SNI :

openssl s_client -connect api.internal.example.com:443 -servername api.internal.example.com -brief -showcerts </dev/null

Recherchez :

• Le sujet du certificat serveur et les SAN incluent le nom d'hôte demandé.
• La chaîne est complète jusqu'à une racine de confiance.
• L'heure système est correcte (la validation TLS dépend d'une heure précise).

Vérification et diagnostics

Définissez à quoi ressemble le succès et capturez des artefacts comparables plus tard.

Signaux de succès attendus par couche :

• DNS : getent hosts retourne un ensemble stable d'IPs correspondant aux résultats dig +short pour A/AAAA selon le cas.
• TCP : nc -vz hôte port signale « succeeded » de façon constante ; pas de délais.
• HTTP : curl -I retourne 2xx/3xx et se termine dans la latence attendue.
• TLS : openssl s_client montre une chaîne valide ; pas d'inadéquation de nom d'hôte ; l'heure système est correcte.
• Routage : ip route get hôte montre l'interface et l'adresse source attendues ; traceroute atteint la destination ou le dernier saut AS que vous contrôlez.
• Pare-feu : la liste des règles et les compteurs sont cohérents avec le trafic autorisé ; pas de DROP inattendu sur les chaînes pertinentes.

Automatisez et stockez un lot de vérification minimal :

TARGET=api.internal.example.com
PORT=443
OUT=verify-$(date +%Y%m%d-%H%M%S); mkdir -p "$OUT"
{
 echo '# DNS'; getent hosts "$TARGET\); dig +short "$TARGET" A; dig +short "$TARGET" AAAA
 echo '# TCP'; nc -vz "$TARGET" "$PORT" 2>&1 | sed 's/^/ /'
 echo '# HTTP'; curl -w '\n%{remote_ip} %{http_code} %{time_total}s\n' -I -sS https://"$TARGET" -o /dev/null
 echo '# ROUTE'; ip route get "$TARGET"
} | tee "$OUT/result.txt"

Examinez result.txt pour des sorties cohérentes et attendues. Conservez ces lots pour comparer entre hôtes ou après modifications.

Modes de défaillance et récupération

Pièges courants et comment les corriger ou annuler proprement.

1. Mauvaise entrée /etc/hosts qui remplace le DNS

• Symptôme : getent hosts nom retourne une IP obsolète qui ne correspond pas à dig.
• Correction : commentez ou supprimez la ligne. Récupération : restaurez la sauvegarde : sudo cp /etc/hosts.bak.<horodatage> /etc/hosts.

1. Ordre nsswitch.conf incorrect causant des recherches lentes ou erronées

• Symptôme : résolution de noms retardée ; résultats inattendus de getent.
• Correction : définissez hosts: files dns (typique). Récupération : restaurez depuis la sauvegarde si les changements n'aident pas.

1. Cache DNS obsolète

• Symptôme : dig vers un amont spécifique montre la nouvelle IP, mais votre système résout l'ancienne IP.
• Correction : videz les caches : sudo resolvectl flush-caches (si disponible) ou redémarrez le résolveur local avec précaution pendant une fenêtre. Récupération : annulez le redémarrage de service s'il impacte d'autres recherches.

1. Chemin IPv6-only ou IPv6-préféré cassé

• Symptôme : curl bloque ; dig AAAA retourne une adresse ; nc -6 -vz échoue alors que -4 fonctionne.
• Correction : préférez IPv4 avec curl -4 ou ajustez l'ordre des résolveurs le temps de corriger la route/pare-feu IPv6. Récupération : retirez les drapeaux temporaires une fois IPv6 corrigé.

1. Pare-feu bloque le port du nouveau service

• Symptôme : nc expire ; traceroute s'arrête avant la cible ; les compteurs augmentent sur les règles DROP.
• Correction (test temporaire) : ajoutez une règle ACCEPT spécifique limitée par source et port ; vérifiez ; puis créez une règle permanente via gestion de changements. Récupération : supprimez la règle de test avec la commande inverse exacte planifiée.

1. Interception proxy ou NO_PROXY incorrect

• Symptôme : hôte interne accessible seulement sans proxy ; avec proxy, TLS échoue ou mauvais certificat présenté.
• Correction : définissez NO_PROXY=.internal.example.com,10.0.0.0/8 approprié. Récupération : annulez ou restaurez les valeurs précédentes.

1. Trou noir MTU

• Symptôme : petits pings fonctionnent ; HTTPS bloque pendant la poignée de main ; ping -M do -s 1472 échoue.
• Correction : définissez un MTU plus bas sur l'interface affectée temporairement pour tester : sudo ip link set dev eth0 mtu 1400 (remplacez eth0 par votre interface) ; si cela fonctionne, coordonnez une correction PMTU permanente sur le réseau. Récupération : revenez en arrière : sudo ip link set dev eth0 mtu 1500 (valeur d'origine).

1. Décalage d'heure cassant TLS

• Symptôme : curl ou openssl s_client signale certificat pas encore valide ou expiré, mais les dates sont correctes ailleurs.
• Correction : corrigez l'heure système et assurez la synchronisation : timedatectl set-ntp true. Récupération : annulez les modifications manuelles d'heure si elles causent de la dérive ; assurez la stabilité NTP.

Liste de contrôle opérationnelle

Utilisez ce manuel pendant les incidents. Remplacez les valeurs factices par les réelles.

1. Capturez la base de référence

• cat /etc/os-release; uname -a; bash --version | head -n1
• ip addr; ip route; ip link; ss -tulpn (sudo si nécessaire)
• cat /etc/resolv.conf; resolvectl status (si disponible)
• env | grep -iE '^(http|https|no)_proxy='

1. Localisez la panne

• getent hosts <nom> ; dig +short <nom> A et AAAA
• nc -vz <nom ou ip> <port>
• curl -I -sS https://<nom> (ajoutez -k seulement pour séparer les échecs TLS de TCP)
• Détail DNS si nécessaire : vérifiez /etc/hosts et /etc/nsswitch.conf
• dig @<serveur_noms> <nom> A +noall +answer
• resolvectl flush-caches (si sûr)
• Routage et chemin : ip route get <nom>, traceroute -T -p <port> <nom>
• ping -M do -s 1472 <nom> (ajustez la taille selon besoin)
• Vérification pare-feu lecture seule : nft list ruleset ou iptables -S
• ufw status verbose ou firewall-cmd --list-all
• Proxy et TLS : examinez les variables proxy ; annulez temporairement http_proxy https_proxy no_proxy
• openssl s_client -connect <nom>:<port> -servername <nom> -brief

1. Vérifiez et enregistrez le résultat

• Sauvegardez les sorties clés ; confirmez les signaux attendus par couche

1. Récupération si vous avez changé quelque chose

• Restaurez /etc/hosts ou nsswitch.conf depuis les sauvegardes
• Supprimez toute règle pare-feu temporaire
• Annulez les changements MTU ou autres d'interface
• Réappliquez les réglages proxy corrects

Conclusion

Un dépannage réseau Bash robuste commence par un inventaire discipliné, puis progresse couche par couche : résolution, accessibilité, routage, filtrage et spécificités applicatives comme les proxys et TLS. En privilégiant les observations en lecture seule, en ne faisant que des modifications minimales et réversibles, et en définissant des signaux de succès clairs, vous réduisez les risques et raccourcissez le temps vers la clarté.

Prochaines étapes possibles dès aujourd'hui :

• Transformez le lot de vérification en petit script qui enregistre les sorties dans des répertoires horodatés.
• Établissez un pilote étroit et mesurable sur un service et un hôte, puis étendez-le au fur et à mesure que les motifs se répètent.
• Gardez un enregistrement léger des résultats attendus (IPs, ports, attributs TLS) pour vos dépendances critiques afin de repérer immédiatement toute dérive.

Avec ces pratiques, vous pouvez diagnostiquer la plupart des problèmes réseau rapidement et en toute confiance, et vous aurez les artefacts pour prouver que chaque correction a fonctionné avant d'étendre les changements plus largement.