## 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
TâcheCommandeSignal de bon fonctionnement attendu
DNS via NSSgetent hosts api.internal.example.comRetourne IP et nom sur une ligne
DNS via résolveurdig +short api.internal.example.comUne ou plusieurs IPs, pas de SERVFAIL
Accessibilité TCPnc -vz api.internal.example.com 443"succeeded" avec l'IP résolue
En-tête HTTPcurl -I https://api.internal.example.com200/301/302, résolution rapide
## Dépannage DNS Validez où votre système obtient les réponses et dans quel ordre. - 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. - 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 - Suivez les chaînes CNAME et les TTL : dig api.internal.example.com +trace +nodnssec | sed -n '1,80p' - 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 - É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
SourceOù vérifierNotes
/etc/hostscat /etc/hostsRemplace le DNS pour les noms exacts
DNS via resolv.confcat /etc/resolv.conf; digListe les serveurs de noms et options
systemd-resolvedresolvectl statusAffiche DNS par liaison et cache
Ordre NSS/etc/nsswitch.confDétermine l'ordre de recherche
## 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 || 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 Pile Commande de liste Notes nftables nft list ruleset Préféré sur distributions modernes iptables iptables -S Affiche règles canoniques et politiques UFW ufw status verbose Résumé lisible firewalld firewall-cmd --list-all Vue par zones ## 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 &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. - 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. /etc/hosts . - 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. - 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. - 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é. - 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. - 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. - 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). - 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. - 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=' - Localisez la panne - getent hosts ; dig +short A et AAAA - nc -vz - curl -I -sS https:// (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 @ A +noall +answer - resolvectl flush-caches (si sûr) - Routage et chemin : ip route get , traceroute -T -p - ping -M do -s 1472 (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 : -servername -brief - Vérifiez et enregistrez le résultat - Sauvegardez les sorties clés ; confirmez les signaux attendus par couche - 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.