Dépannage réseau Bash avec exemples pratiques : guide d'implémentation

Introduction

Lorsqu'un service n'arrive pas à joindre une destination, la cause se situe presque toujours dans l'un de ces cinq domaines : résolution de nom, joignabilité, routage, filtrage, ou problématique de couche applicative (TLS, configuration de proxy). 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, vérifiables et reproductibles, utilisables sur des postes de développement comme sur des serveurs.

Vous apprendrez à :

Dresser l'inventaire de votre environnement et de l'état réseau
Lancer des contrôles rapides et en lecture seule pour localiser la panne
Inspecter DNS, ports, routes, pare-feu, proxys et TLS
Interpréter les résultats attendus et éviter les faux positifs
Revenir proprement de petits changements temporaires
Créer une check-list d'exploitation réutilisable

Remplacez les noms d'hôtes, domaines et adresses par ceux de votre environnement. Pour garder la cohérence avec la recherche, vous verrez ponctuellement les expressions Bash networking, Bash DNS, Bash ports, Bash connectivity et Bash network troubleshooting, intégrées naturellement.

Inventaire des versions et de l'environnement

Avant tout changement, capturez l'existant pour accélérer l'analyse et disposer d'une base de comparaison.

Commandes pour figer les versions système et outils :

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

# Bash et outils réseau de base
bash --version | head -n1
ip -V || 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 de l'heure impacte la validation TLS
command -v timedatectl >/dev/null && timedatectl

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

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

# Route par défaut et décision de routage vers une cible (exemple construit)
ip route get 203.0.113.10

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

# Ordre de résolution (NSS)
grep -E '^[[:space:]]*hosts:' /etc/nsswitch.conf || echo 'nsswitch.conf hosts entry not found'

Contexte du service :

# Écouteurs locaux (sudo requis pour les noms de processus)
sudo ss -tulpn

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

Conservez ces clichés dans un répertoire horodaté pour comparer 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

Approche étroite, réversible et observable :

Périmètre : choisissez un seul nom d'hôte et un port à étudier (ex. api.example.test en TCP 443). Évitez les changements globaux tant que la panne n'est pas reproduite et localisée.
Sauvegardes : avant d'éditer /etc/hosts ou /etc/nsswitch.conf, sauvegardez : sudo cp /etc/hosts /etc/hosts.bak.$(date +%s).
Lecture seule d'abord : privilégiez ip, ss, dig, curl -v à toute commande modifiant l'état.
Changements temporaires et minimaux : consignez aussitôt la commande d'annulation.
Validation locale : prouvez chaque étape en capturant la sortie et en la comparant à la ligne de base.

Tests de connectivité de base

Ces vérifications rapides indiquent la zone à approfondir.

# 1) La cible IP répond-elle ? (IP d'exemple)
ping -c 2 203.0.113.10 || echo 'ICMP peut être filtré; poursuivre avec des tests TCP'

# 2) Résolution du nom vers une IP ?
getent hosts api.example.test || true

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

# 4) Forcer IPv6/IPv4 pour isoler les soucis par famille
dig +timeout=2 +tries=1 api.example.test AAAA

# 5) Si vous avez l'IP attendue, tester la joignabilité TCP (IP d'exemple)
nc -vz 203.0.113.10 443

# 6) Tester rapidement la couche applicative (sans corps)
curl -I -sS https://api.example.test || curl -vkI https://api.example.test

Interprétation :

Le nom se résout mais le TCP échoue : routage, pare-feu ou indisponibilité du service cible.
Le nom ne se résout pas : concentrez-vous sur la configuration DNS et ses sources.
IPv4 OK mais IPv6 KO (ou l'inverse) : examinez le double-stack, les enregistrements AAAA et les filtrages par famille.
TCP OK mais HTTP/TLS KO : vérifiez les variables de proxy, le SNI et la chaîne de certificats.

Référence rapide :

DNS via NSS : getent hosts api.example.test doit retourner IP et nom.
DNS via résolveur : dig +short api.example.test doit fournir des IPs sans SERVFAIL.
Joignabilité TCP : nc -vz api.example.test 443 doit indiquer « succeeded ».
HTTP HEAD : curl -I https://api.example.test doit répondre 200/301/302 rapidement.

Dépannage DNS

Validez d'où viennent les réponses et dans quel ordre.

Inspecter les sources et l'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, systemd-resolved est probablement actif ; utilisez resolvectl pour voir les DNS amont.
nsswitch.conf avec hosts: files dns signifie que /etc/hosts est consulté avant le DNS.

Comparer les réponses selon la source :

# Vue NSS
getent hosts api.example.test

# Résolveur courant
dig +nocmd api.example.test A +noall +answer

# Interroger un serveur DNS précis (IP d'exemple)
dig @192.0.2.53 api.example.test A +noall +answer

# Comparer AAAA vs A
dig api.example.test AAAA +short; dig api.example.test A +short

Suivre les chaînes CNAME et les TTL :

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

Vider les caches (effet temporaire) :

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

Épingler temporairement un hôte (exemple) :

sudo cp /etc/hosts /etc/hosts.bak.$(date +%s)
echo '203.0.113.10 api.example.test' | sudo tee -a /etc/hosts
getent hosts api.example.test
# Restaurez ensuite la sauvegarde ou supprimez la ligne

Signaux typiques :

SERVFAIL/REFUSED : problème côté DNS amont ou type de requête bloqué.
NXDOMAIN pour A mais AAAA valide (ou inverse) : décalage IPv4/IPv6.
getent diverge de dig : /etc/hosts ou l'ordre nsswitch.conf influe.

Ports et services

Déterminez si quelque chose écoute localement, si un port distant est atteignable et ce que dit l'application.

Écouteurs locaux :

# Remarque : sudo souvent requis pour les détails process
sudo ss -tulpn | sed -n '1,50p'

Champs clés :

Local Address: Port indique les interfaces liées (0.0.0.0 = tout IPv4, :: = tout IPv6).
L'état LISTEN confirme l'écoute serveur.

Joignabilité distante et bannières :

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

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

# Détails TLS, SNI et chaîne de certificats
openssl s_client -connect api.example.test:443 -servername api.example.test -brief -showcerts </dev/null

Interprétation :

Connection refused : hôte atteignable mais rien n'écoute sur ce port.
Connection timed out : routage ou pare-feu probablement bloquant ; inspectez le chemin et le filtrage.
TLS : « unknown CA » ou « hostname mismatch » → certifs/SNI à corriger.

Routage et MTU

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

Route choisie :

ip route get api.example.test

Tracer le chemin et localiser le blocage :

# traceroute TCP passe souvent quand l'ICMP est filtré
sudo traceroute -T -p 443 api.example.test 2>/dev/null || traceroute api.example.test

Détecter les trous PMTU (tailles d'exemple) :

# Tester avec DF (ne pas fragmenter) et tailles croissantes en IPv4
ping -M do -s 1472 -c 2 api.example.test  # 1472 + 28 d'en-tête ≈ MTU 1500
ping -M do -s 8972 -c 2 api.example.test  # Pour chemins jumbo, si attendu

Signaux :

Routage asymétrique : chemins aller/retour différents, visible via traceroute vs journaux serveur.
Problème PMTU : petites requêtes OK, handshakes TLS bloqués ; pings DF échouent au-delà d'un seuil.

Vérifications du pare-feu

Privilégiez l'inspection en lecture seule. N'altérez pas les politiques sans fenêtre planifiée et plan de retour arrière.

Lister les règles selon les piles courantes :

# nftables (moderne)
sudo nft list ruleset

# iptables (héritage ou compat)
sudo iptables -S; sudo iptables -L -n -v

# UFW (front-end iptables)
sudo ufw status verbose

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

Points d'attention :

Les politiques DROP/REJECT avec compteurs croissants trahissent souvent un filtrage au niveau de la chaîne.
Les règles DNAT/SNAT peuvent rediriger ; confirmez toujours la destination après NAT.

Si une règle temporaire est nécessaire, préparez d'abord la commande inverse. Exemple iptables (construit) :

# Planifier l'ajout et la suppression avant toute exécution :
# Ajouter (exemple) : sudo iptables -I INPUT -p tcp --dport 443 -s 198.51.100.0/24 -j ACCEPT
# Supprimer (rollback) : sudo iptables -D INPUT -p tcp --dport 443 -s 198.51.100.0/24 -j ACCEPT

Proxys et TLS

Les proxys silencieux et les problèmes de certificats miment souvent des pannes réseau.

Détecter et interpréter les variables de proxy :

env | grep -iE '^(http|https|no)_proxy='
# Nettoyage pour tester (portée shell uniquement)
unset http_proxy https_proxy no_proxy HTTP_PROXY HTTPS_PROXY NO_PROXY

Tester avec/sans proxy. Si un proxy d'entreprise est requis, test explicite :

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

Valider la poignée de main TLS et le SNI :

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

Recherchez :

Le certificat inclut le nom d'hôte (subject/SAN).
La chaîne est complète jusqu'à une racine de confiance.
L'heure système est correcte (critique pour la validation TLS).

Vérification et diagnostics

Définissez des signaux de réussite et archivez des artefacts comparables.

Signaux attendus par couche :

DNS : getent hosts renvoie un ensemble d'IP stable, aligné avec dig +short (A/AAAA).
TCP : nc -vz host port réussit de façon consistante, sans timeouts.
HTTP : curl -I retourne 2xx/3xx dans la latence prévue.
TLS : openssl s_client montre une chaîne valide, pas d'erreur de nom ; heure correcte.
Routage : ip route get host indique l'interface et l'adresse source attendues ; traceroute atteint la destination ou le dernier AS contrôlé.
Pare-feu : règles et compteurs cohérents avec le trafic autorisé, pas de drops inattendus.

Automatiser un bundle de vérification (cible d'exemple) :

TARGET=api.example.test
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 et conservez ces bundles pour comparer entre hôtes ou après changements. Utile aussi dans des environnements Docker, Docker Compose, Kubernetes (Ingress, Secrets) où les couches réseau/logiques s'additionnent.

Modes de panne et remédiations

Mauvaise entrée /etc/hosts qui outrepasse le DNS

Symptôme : getent hosts retourne une IP obsolète, différente de dig.
Correctif : commenter/supprimer la ligne. Restauration : remettre la sauvegarde.

Ordre nsswitch.conf inadapté

Symptôme : résolutions lentes ou erronées.
Correctif : hosts: files dns (typique). Restauration si inefficace.

Cache DNS périmé

Symptôme : dig vers un DNS amont montre la nouvelle IP, mais le système résout l'ancienne.
Correctif : sudo resolvectl flush-caches (si dispo) ou redémarrer prudemment le résolveur.

Chemin IPv6 défaillant

Symptôme : curl se fige, dig AAAA renvoie une adresse, nc -6 -vz échoue alors que -4 marche.
Correctif : forcer IPv4 temporairement (curl -4) ou ajuster l'ordre de résolution le temps de corriger IPv6.

Pare-feu qui bloque un nouveau port service

Symptôme : nc timeouts, traceroute s'arrête avant la cible, compteurs DROP augmentent.
Correctif (test) : règle ACCEPT spécifique et limitée, puis mise en conformité via le processus normal. Rollback : commande inverse prévue.

Proxy interceptant ou NO_PROXY mal réglé

Symptôme : un hôte interne n'est joignable qu'en dehors du proxy ; via proxy, TLS échoue ou présente un mauvais certificat.
Correctif : ajuster NO_PROXY=.example.test,10.0.0.0/8. Restauration : rétablir les valeurs précédentes.

Trou de MTU

Symptôme : petits pings OK ; TLS se fige ; ping -M do -s 1472 échoue.
Correctif : MTU plus bas temporairement : sudo ip link set dev eth0 mtu 1400 (interface d'exemple) ; si concluant, coordonner une correction PMTU réseau. Rollback : sudo ip link set dev eth0 mtu 1500.

Dérive d'heure qui brise TLS

Symptôme : curl/openssl s_client indique « not yet valid/expired » alors que la date attendue est correcte ailleurs.
Correctif : corriger l'heure et activer NTP : timedatectl set-ntp true.

Check-list opérations

Capturer la base

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 présent)
env | grep -iE '^(http|https|no)_proxy='

Localiser la panne

getent hosts <nom> ; dig +short <nom> A et AAAA
nc -vz <nom ou ip> <port>
curl -I -sS https://<nom> (ajoutez -k uniquement pour séparer TLS de TCP)

Détails DNS si besoin

Inspecter /etc/hosts et /etc/nsswitch.conf
dig @<ip_dns> <nom> A +noall +answer
resolvectl flush-caches (si sans risque)

Routage et chemin

ip route get <nom ou ip>
traceroute -T -p <port> <nom>
ping -M do -s 1472 <nom> (ajuster la taille)

Pare-feu en lecture seule

nft list ruleset ou iptables -S
ufw status verbose ou firewall-cmd --list-all

Proxy et TLS

Revoir les proxys ; temporairement unset http_proxy https_proxy no_proxy
openssl s_client -connect <nom>:<port> -servername <nom> -brief

Vérifier et consigner

Sauvegarder les sorties ; confirmer les signaux par couche

Restauration si changement

Restaurer /etc/hosts ou nsswitch.conf
Supprimer les règles pare-feu temporaires
Rétablir MTU et paramètres réseau
Réappliquer les proxys corrects

Conclusion

Un dépannage réseau Bash robuste commence par un inventaire discipliné, puis avance couche par couche : résolution, joignabilité, routage, filtrage et aspects applicatifs (proxys, TLS). En privilégiant l'observation en lecture seule, des changements minimaux et réversibles, et des critères de succès clairs, vous réduisez le risque et accélérez la compréhension. Prochaines étapes :

Transformer le bundle de vérification en script qui enregistre des sorties horodatées.
Démarrer un pilote ciblé sur un service et un hôte, puis étendre.
Tenir un relevé léger des résultats attendus (IPs, ports, attributs TLS) pour repérer immédiatement toute dérive.

Avec cette méthode, la majorité des incidents de connectivité Bash peuvent être diagnostiqués rapidement et de manière fiable, preuves à l'appui, avant de généraliser les correctifs.