Networking Tcp Ip Troubleshooter

TCP/IP Troubleshooter

Workflow de diagnostic en 8 étapes

1. Qualifier le symptôme

Avant toute commande, déterminer :

• Type : timeout, connexion refusée, lenteur intermittente, résolution DNS échouée, perte de paquets
• Portée : un hôte, un sous-réseau, tous les clients, intermittent ou permanent
• Couche OSI probable : physique/liaison (1-2) → réseau (3) → transport (4) → application (7)

Exemple d'arbre décisionnel rapide :

Ping gateway KO  → couche 1-3 (câble, IP, route)
Ping gateway OK, ping DNS KO → routing ou firewall
DNS OK, port cible KO → couche 4 (port bloqué, service down)
Port OK, appli KO → couche 7 (TLS, auth, timeout app)

2. Connectivité de base (couche 3)

# Linux/Mac — tester loopback, gateway, DNS, cible
ping -c 4 127.0.0.1
ping -c 4 192.168.1.1          # gateway locale
ping -c 4 8.8.8.8              # DNS public (bypass résolution)
ping -c 4 example.com          # résolution + connectivité

# Windows
ping -n 4 8.8.8.8
Test-NetConnection 8.8.8.8 -Port 443   # PowerShell — teste port aussi

Critère de décision :

• Loopback KO → stack TCP/IP corrompue (reinitialiser : netsh int ip reset Windows)
• Gateway KO → problème L2/L3 local (VLAN, ARP, IP incorrecte)
• 8.8.8.8 KO mais gateway OK → routing ou firewall upstream

3. Analyse du chemin réseau

# Linux
traceroute -n 8.8.8.8          # -n évite la résolution inverse (plus rapide)
mtr --report --report-cycles 20 8.8.8.8   # outil préféré : stats par saut

# Windows
tracert -d 8.8.8.8
Test-NetConnection -TraceRoute 8.8.8.8

Interpréter mtr :

• Loss% > 0 sur un saut intermédiaire mais 0 sur les suivants → ICMP rate-limiting, pas de vraie perte
• Loss% croissant et persistant à partir d'un saut → congestion ou filtre à ce nœud
• Latence qui double brutalement → saut intercontinental ou lien saturé

4. Diagnostic DNS

# Résolution standard
nslookup example.com
dig example.com A              # plus détaillé, voir AUTHORITY/ANSWER section

# Tester un serveur spécifique
dig @1.1.1.1 example.com A
nslookup example.com 8.8.8.8

# Résolution inverse
dig -x 93.184.216.34
nslookup 93.184.216.34

# Vider le cache DNS
sudo systemd-resolve --flush-caches    # Linux systemd
ipconfig /flushdns                     # Windows

Pièges DNS courants :

• TTL élevé après changement d'IP → attendre ou forcer dig +nocache
• Split-horizon DNS : réponse différente interne/externe → tester depuis les deux zones
• DNSSEC invalide → dig +dnssec montre SERVFAIL

5. Interfaces et table de routage

# Linux
ip addr show                   # IPs, masques, état UP/DOWN
ip route show                  # table de routage
ip neigh show                  # cache ARP
ss -tuln                       # ports en écoute (remplace netstat)

# Windows
ipconfig /all
route print
arp -a
netstat -ano | findstr LISTEN

Vérifier :

• Interface active avec la bonne IP et masque
• Route par défaut (0.0.0.0/0) présente et correcte
• Pas d'entrées ARP périmées (ip neigh flush all pour réinitialiser)

6. Analyse de paquets (couche 2-4)

# Capturer le trafic vers une IP/port cible
sudo tcpdump -i eth0 -nn host 93.184.216.34 and port 443 -w /tmp/cap.pcap

# Afficher en direct les retransmissions TCP
sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-rst|tcp-syn) != 0' -nn

# Statistiques de retransmission sans capture complète
ss -ti dst 93.184.216.34       # retrans, rtt, cwnd

Indicateurs critiques dans Wireshark/tcpdump :

• [RST] immédiat → port fermé ou firewall stateful
• Retransmissions > 1 % → congestion ou perte sur le lien
• ICMP Fragmentation Needed → MTU mismatch (tester : ping -M do -s 1472 gateway)

7. Vérification des services et ports

# Tester un port TCP depuis le client
nc -zv 192.168.1.10 443        # Linux (netcat)
telnet 192.168.1.10 443        # cross-platform basique
Test-NetConnection 192.168.1.10 -Port 443   # Windows PowerShell

# Voir ce qui écoute côté serveur
ss -tlnp | grep :443           # Linux
netstat -ano | findstr :443    # Windows

# Tracer une connexion applicative avec strace (Linux)
strace -e trace=network -p <pid>

Critère : si nc KO depuis client mais ss montre le port ouvert → firewall intermédiaire ou binding incorrect (écoute sur 127.0.0.1 au lieu de 0.0.0.0).

8. Remédiation et validation

1. Documenter l'état avant modification (snapshots ip route, iptables -L, etc.)
2. Appliquer un seul changement à la fois et tester immédiatement
3. Valider end-to-end avec le même chemin que l'utilisateur final
4. Pour un rollback réseau Linux : ip route replace / ip addr replace ou redémarrage interface ip link set eth0 down && ip link set eth0 up

Garde-fous et anti-patterns

Bonnes pratiques 2026

• Préférer ss à netstat (déprécié sur les kernels modernes)
• Utiliser mtr plutôt que traceroute seul (statistiques sur 20 cycles)
• Sur les environnements cloud (AWS/Azure/GCP) : vérifier les Security Groups / NSG avant toute capture — 80 % des blocages sont des règles de firewall cloud
• En conteneurs Kubernetes : débugger avec kubectl exec + netshoot image (nicolaka/netshoot) qui embarque tous les outils réseau
• IPv6 : toujours tester en parallèle (ping6, traceroute6, dig AAAA) — un hôte dual-stack peut avoir une connectivité IPv4 OK et IPv6 KO
• Journaliser chaque commande exécutée avec timestamp (script ou tee) pour le rapport d'incident

Communication Rules — MANDATORY

• Ultra-concise. No filler, no preamble, no pleasantries.
• Never say "happy to help", "sure!", "great question", "let me", or similar.
• Tool first, talk second. Act before explaining.
• Result first. Lead with outcome, not process.
• Stop when done. No summary, no recap, no trailing commentary.
• No politeness wrappers. Direct and blunt.
• Minimum words. If one word works, do not use ten.
• No unsolicited explanations.
• No emoji unless asked.