Diagnostiquer un problème réseau avec tcpdump et Wireshark

Diagnostiquer un problème réseau avec tcpdump et Wireshark

Capturez et analysez le trafic réseau de votre VPS avec tcpdump (CLI) et Wireshark (GUI). Apprenez à identifier rapidement les causes des problèmes : timeouts, latences, paquets perdus, certificats SSL invalides, requêtes HTTP malformées.

Introduction

Quand une connexion ne marche pas et que les logs ne disent rien, il faut aller voir les paquets eux-mêmes. C'est le rôle de tcpdump (CLI) et Wireshark (GUI). Vous identifiez :

  • Quels paquets entrent/sortent
  • Si le handshake TCP/TLS aboutit
  • Quelles erreurs apparaissent (RST, retransmissions)
  • Quelles latences chaque étape prend

Indispensable pour un sysadmin réseau.

Prérequis

  • VPS Linux avec accès root
  • 5 minutes de patience pour relire les options de tcpdump
  • Pour Wireshark : poste local Windows/macOS/Linux

Étape 1 : Installation

tcpdump (sur le VPS)

sudo apt install -y tcpdump
sudo tcpdump --version

Wireshark (sur votre poste)

Étape 2 : Capture basique avec tcpdump

sudo tcpdump -i eth0

⚠️ Tape sur tout le trafic, illisible en quelques secondes. On filtre toujours.

Filtres essentiels

# Trafic vers/depuis un host
sudo tcpdump -i eth0 host 1.2.3.4

# Port spécifique
sudo tcpdump -i eth0 port 443

# IP source ou destination
sudo tcpdump -i eth0 src 1.2.3.4
sudo tcpdump -i eth0 dst 1.2.3.4

# Combinaisons
sudo tcpdump -i eth0 host 1.2.3.4 and port 443

# Tout sauf SSH (pour pas polluer avec votre propre connexion)
sudo tcpdump -i eth0 not port 22

# Protocole
sudo tcpdump -i eth0 icmp
sudo tcpdump -i eth0 udp

Étape 3 : Options utiles

sudo tcpdump -i eth0 -n -nn -v -tttt port 443

# -n   : pas de résolution DNS (rapide)
# -nn  : pas de résolution port → nom de service
# -v   : verbose (TTL, ID, etc.)
# -tttt: timestamps lisibles
# -c 100 : arrêter après 100 paquets
# -s 0 : capturer tout le paquet (pas tronqué à 96 bytes)

Sauvegarder dans un fichier .pcap pour Wireshark

sudo tcpdump -i eth0 -w /tmp/capture.pcap port 443

Téléchargez le fichier via scp :

scp user@IP_VPS:/tmp/capture.pcap ~/Desktop/

Ouvrez-le dans Wireshark pour une analyse visuelle.

Étape 4 : Lire une capture

sudo tcpdump -r /tmp/capture.pcap -nn

Sortie type :

15:30:00.123456 IP 1.2.3.4.54321 > 5.6.7.8.443: Flags [S], seq 12345, win 65535
15:30:00.143789 IP 5.6.7.8.443 > 1.2.3.4.54321: Flags [S.], seq 67890, ack 12346, win 65535
15:30:00.144000 IP 1.2.3.4.54321 > 5.6.7.8.443: Flags [.], ack 67891, win 65535

C'est un handshake TCP normal : SYN, SYN-ACK, ACK.

Flags TCP

  • S (SYN) : initiation de connexion
  • . (ACK) : accusé de réception
  • S. (SYN-ACK) : réponse à un SYN
  • F (FIN) : fermeture propre
  • R (RST) : reset, fin abrupte (erreur)
  • P (PUSH) : données à pousser immédiatement

Étape 5 : Diagnostiquer un problème de connexion

Symptôme : "Connection refused"

sudo tcpdump -i eth0 -nn host 5.6.7.8 and port 443

Si vous voyez :

1.2.3.4.54321 > 5.6.7.8.443: Flags [S]
5.6.7.8.443 > 1.2.3.4.54321: Flags [R]

→ Le serveur reset. Le port 443 n'écoute pas (service down ou pas démarré).

Symptôme : Timeout

sudo tcpdump -i eth0 -nn host 5.6.7.8 and port 443

Si vous voyez :

1.2.3.4.54321 > 5.6.7.8.443: Flags [S]
[retransmissions du SYN toutes les ~1s, ~3s, ~7s...]

→ Aucune réponse du serveur. Causes possibles :

  • Firewall qui drop silencieusement
  • Routage cassé
  • Serveur down

Symptôme : "Connection reset"

[handshake OK]
1.2.3.4.54321 > 5.6.7.8.443: Flags [P.], data
5.6.7.8.443 > 1.2.3.4.54321: Flags [R]

→ Le serveur reset une fois la connexion établie. Souvent : application qui crash, rate limiter qui se déclenche, ou WAF qui bloque.

Étape 6 : Diagnostiquer le DNS

sudo tcpdump -i eth0 -nn port 53

Vous voyez les requêtes/réponses DNS :

1.2.3.4.45678 > 1.1.1.1.53: A? google.com.
1.1.1.1.53 > 1.2.3.4.45678: A 142.250.74.110

Si la requête sort mais pas de réponse : problème avec le résolveur. Changez :

echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf

Étape 7 : Diagnostiquer SSL/TLS

sudo tcpdump -i eth0 -nn -s 0 -w /tmp/tls.pcap port 443

Ouvrez dans Wireshark → filtrez tls.handshake.type == 1 (ClientHello).

Vous voyez :

  • Version TLS demandée (1.2, 1.3)
  • Cipher suites supportées
  • SNI (nom du domaine demandé)

Pour les erreurs SSL :

  • TLS Alert 50 (decode_error) : paquet TLS malformé
  • TLS Alert 40 (handshake_failure) : pas de cipher en commun
  • TLS Alert 42 (bad_certificate) : cert invalide
  • TLS Alert 70 (protocol_version) : version TLS pas supportée

Étape 8 : Diagnostiquer la latence

sudo tcpdump -i eth0 -nn -tttt host 5.6.7.8 and port 443

Notez les timestamps :

15:30:00.123456 1.2.3.4.54321 > 5.6.7.8.443: [S]
15:30:00.143789 5.6.7.8.443 > 1.2.3.4.54321: [S.]    ← 20ms (RTT)

20ms entre SYN et SYN-ACK = RTT (round-trip time). Normal en France métropolitaine.

Détecter les retransmissions

Dans Wireshark → filtre : tcp.analysis.retransmission. Trop de retransmissions = lien instable.

Détecter les paquets dupliqués

1.2.3.4 > 5.6.7.8: ack 100 win 65535
1.2.3.4 > 5.6.7.8: ack 100 win 65535   ← Dup ACK

Trois Dup ACK consécutifs déclenchent un fast retransmit (perte détectée).

Étape 9 : Capturer le payload HTTP

sudo tcpdump -i eth0 -nn -s 0 -A 'port 80 and host 5.6.7.8'

-A affiche le payload ASCII. Vous voyez les requêtes HTTP en clair :

GET / HTTP/1.1
Host: example.com
User-Agent: curl/7.88.1

⚠️ Pour HTTPS, le payload est chiffré. Pour le déchiffrer, voir étape 10.

Étape 10 : Déchiffrer HTTPS dans Wireshark

Si vous avez la clé privée du serveur ou les pre-master secrets du client, Wireshark peut déchiffrer le TLS.

Méthode rapide : exportez les pre-master secrets depuis votre navigateur.

# Sur votre poste, avant de lancer Firefox/Chrome
export SSLKEYLOGFILE=/tmp/sslkeys.log
firefox &

Faites votre test → fermez le navigateur.

Dans Wireshark → Edit → Preferences → Protocols → TLS → "(Pre)-Master-Secret log filename" → pointez vers /tmp/sslkeys.log.

Le trafic HTTPS apparaît maintenant déchiffré dans la capture.

Étape 11 : Filtres Wireshark avancés

Wireshark a un langage de filtre différent de tcpdump (plus puissant) :

WiresharkDescription
ip.addr == 1.2.3.4Trafic vers/depuis 1.2.3.4
tcp.port == 443Port 443 (src OU dst)
httpTout le trafic HTTP
http.requestUniquement les requêtes
http.response.code == 500Erreurs 500
tls.handshakeHandshakes TLS
dnsDNS
icmpICMP
tcp.flags.reset == 1Paquets avec flag RST
tcp.analysis.retransmissionRetransmissions
tcp.window_size == 0Zero window (congestion)

Combinaisons : &&, ||, !.

http.request && ip.addr == 1.2.3.4 && !tcp.port == 80

Étape 12 : tshark (Wireshark CLI)

Pour traiter une capture en CLI :

sudo apt install -y tshark

# Lire une capture
tshark -r /tmp/capture.pcap

# Filtrer
tshark -r /tmp/capture.pcap -Y "http.response.code == 500"

# Stats
tshark -r /tmp/capture.pcap -q -z conv,tcp

# Extraire les URLs
tshark -r /tmp/capture.pcap -Y http.request -T fields -e http.host -e http.request.uri

Étape 13 : Captures persistantes (rotation)

Pour capturer en continu sans saturer le disque :

sudo tcpdump -i eth0 -w /var/log/captures/cap-%Y-%m-%d-%H.pcap \
    -G 3600 -W 24 \
    not port 22
  • -G 3600 : rotation toutes les heures
  • -W 24 : garde 24 fichiers (= 1 jour)
  • -w avec strftime %Y-%m-%d-%H : un fichier par heure

Dépannage

"tcpdump: : You don't have permission" {#tcpdump-interface-you-dont-have-permission}

Lancez avec sudo. Ou ajoutez votre user au groupe pcap / capabilities CAP_NET_RAW.

Trop de paquets, illisible

Filtrez plus précisément. Évitez de capturer sur l'interface qui porte votre SSH (sinon votre propre trafic SSH inonde la sortie). Utilisez not port 22.

"Truncated packet"

Augmentez la snaplen :

sudo tcpdump -i eth0 -s 0  # capturer le paquet entier

Capture sur loopback

Pour le trafic localhost :

sudo tcpdump -i lo

Wireshark refuse d'ouvrir le pcap

Vérifiez les permissions du fichier après scp. Peut nécessiter chmod 644.

Commandes utiles

# Lister les interfaces
sudo tcpdump -D

# Stats à la fin d'une capture
sudo tcpdump -i eth0 -c 100 port 443
# packets captured / packets received / dropped

# Capture avec rotation par taille
sudo tcpdump -i eth0 -w /tmp/cap -C 100 -W 10
# -C 100 = 100 MB max par fichier, -W 10 = 10 fichiers

# Combiner tcpdump et tshark via pipe
sudo tcpdump -i eth0 -nn -w - port 443 | tshark -r - -Y "tls.handshake.type == 1"

# Voir les top talkers
sudo tcpdump -i eth0 -nn -c 1000 not port 22 | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head

# Test latence avec tcpdump
sudo tcpdump -i eth0 -nn -tttt host 5.6.7.8 and port 443

Conclusion

tcpdump + Wireshark sont les outils ultimes pour :

  • Confirmer où un problème se situe (réseau, DNS, app, TLS)
  • Mesurer les latences réelles
  • Capter du trafic suspect pour analyse forensique

Pour aller plus loin :

  • mitmproxy : MITM HTTPS pour voir le trafic chiffré
  • Suricata / Zeek : IDS basé sur de la capture continue
  • ntopng : analyse réseau via web UI
  • iperf3 : tester la bande passante entre deux hosts

Ressources

Rejoignez notre serveur communautaire Discord

Pour toute question, suggestion ou simplement pour discuter avec la communauté, rejoignez-nous sur Discord !

900+Membres