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)
- Windows / macOS : https://www.wireshark.org/download.html
- Linux :
sudo apt install wireshark(cochez "Allow non-root capture")
É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éceptionS.(SYN-ACK) : réponse à un SYNF(FIN) : fermeture propreR(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) :
| Wireshark | Description |
|---|---|
ip.addr == 1.2.3.4 | Trafic vers/depuis 1.2.3.4 |
tcp.port == 443 | Port 443 (src OU dst) |
http | Tout le trafic HTTP |
http.request | Uniquement les requêtes |
http.response.code == 500 | Erreurs 500 |
tls.handshake | Handshakes TLS |
dns | DNS |
icmp | ICMP |
tcp.flags.reset == 1 | Paquets avec flag RST |
tcp.analysis.retransmission | Retransmissions |
tcp.window_size == 0 | Zero 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)-wavec 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
- Documentation tcpdump : https://www.tcpdump.org/manpages/tcpdump.1.html
- Wireshark : https://www.wireshark.org
- Display Filter Reference : https://wiki.wireshark.org/DisplayFilters
- Tuto VeryCloud — Tuning kernel :
/docs/article/kernel-tuning - Tuto VeryCloud — IPv6 :
/docs/article/ipv6


















