O tcpdump é uma das ferramentas mais diretas pra troubleshooting. Se você souber filtrar bem, resolve problema rápido, sem depender de interface gráfica.
A ideia aqui é justamente essa: filtros úteis de verdade, do dia a dia.
Se você não filtrar direito, vira lixo de pacote na tela.
Para este tutorial, vamos usar uma das redes de documentação tipo RFC 5737 (192.0.2.0/24) só pra exemplo, no ambiente real, seja específico.
Interface
tcpdump -i eth0
Host específico
tcpdump host 192.0.2.1
Origem
tcpdump src 192.0.2.1
Destino
tcpdump dst 192.0.2.5
Rede
tcpdump net 192.0.2.0/24
Rede por direção
tcpdump src net 192.0.2.0/24
tcpdump dst net 192.0.2.0/24
Dica prática: sempre que possível, já entra com src ou dst. Isso reduz MUITO o ruído.
Aqui você começa a montar filtro que presta.
ARP (bom pra ver bagunça na rede)
tcpdump arp
Se tiver muito who-has, pode ser scan, loop ou broadcast exagerado.
Múltiplas portas
tcpdump port 20 or port 21
Filtro combinado
tcpdump dst 192.0.2.1 and src net 192.0.2.0/24 and not icmp
Aqui é onde muita gente erra: filtro mal feito = análise errada.
Se você entende flag TCP, você entende o que tá acontecendo na conexão.
SYN (tentativa de conexão)
tcpdump 'tcp[tcpflags] == tcp-syn'
ACK
tcpdump 'tcp[tcpflags] == tcp-ack'
RST (reset — geralmente problema)
tcpdump 'tcp[tcpflags] == tcp-rst'
FIN (encerramento)
tcpdump 'tcp[tcpflags] == tcp-fin'
PSH
tcpdump 'tcp[tcpflags] == tcp-push'
URG
tcpdump 'tcp[tcpflags] == tcp-urg'
Exemplo real: muito RST = aplicação recusando, firewall dropando ou serviço inexistente.
Aqui já é análise mais sensível.
Protocolos em texto claro
tcpdump port http or port ftp or port smtp or port imap or port pop3 or port telnet -lA | egrep -i -B5 'user|pass|pwd|login'
Isso aqui é útil pra lab, troubleshooting específico… mas em produção tem que tomar cuidado (principalmente por questão de segurança e LGPD).
Quando o problema não é óbvio, salva e abre no Wireshark.
Gravar
tcpdump -w captura.pcap
Ler depois
tcpdump -r captura.pcap
Boa prática: sempre que o problema for intermitente, grava. Analisar depois com calma salva tempo.
Se você ignorar isso, o próprio tcpdump vira o problema.
Limitar pacotes
tcpdump -c 50
Sem resolução de nome (ESSENCIAL)
tcpdump -n
Exemplo decente pra uso real
tcpdump -n -c 100 -i eth0 icmp and src 192.0.2.1
Regra simples: sempre usa -n.
Se não usar, ele tenta resolver DNS reverso pra cada pacote, em rede grande, isso destrói CPU e ainda atrasa a captura.
Rodar tcpdump é fácil. Difícil é olhar a saída e entender o comportamento.
Aqui vai o que você precisa bater o olho e já sacar.
Exemplo:
14:32:10.123456 IP 192.0.2.10.54321 > 198.51.100.20.80: Flags [S], seq 123456789, win 64240, length 0
Quebrando isso:
Timestamp → 14:32:10.123456
Origem → 192.0.2.10:54321
Destino → 198.51.100.20:80
Flag → [S] (SYN)
Seq → número de sequência
Length → tamanho do payload
Se você ignorar flags e sequência, você perde metade da análise.
O padrão esperado:
[SYN] Cliente → Servidor
[SYN,ACK] Servidor → Cliente
[ACK] Cliente → Servidor
Na prática no tcpdump:
Client > Server: Flags [S]
Server > Client: Flags [S.]
Client > Server: Flags [.]
Se isso não fecha, já tem problema.
1. SYN sem resposta (timeout)
Client > Server: Flags [S]
Client > Server: Flags [S]
Client > Server: Flags [S]
Interpretação:
Servidor não respondeu
Firewall dropando
Rota inexistente
Serviço down
Clássico de bloqueio silencioso (DROP)
2. RST imediato
Client > Server: Flags [S]
Server > Client: Flags [R.]
Interpretação:
Porta fechada
Serviço não está escutando
Firewall rejeitando (REJECT)
Diferença importante:
RST = resposta ativa
Sem resposta = DROP
3. Conexão fecha do nada
Client > Server: Flags [P.]
Server > Client: Flags [R.]
Interpretação:
Aplicação derrubando conexão
Timeout interno
Problema em backend (muito comum em API)
4. Retransmissão (rede ruim)
Você vai ver repetição de sequência:
Client > Server: seq 1000
Client > Server: seq 1000
Client > Server: seq 1000
Interpretação:
Perda de pacote
Latência alta
Congestionamento
Problema físico (link, rádio, etc.)
Em ambiente ISP isso aparece MUITO
5. ACK duplicado
Server > Client: ACK 2000
Server > Client: ACK 2000
Server > Client: ACK 2000
Interpretação:
Pacote perdido no caminho
Indica retransmissão iminente
Cliente reclama que “não acessa”
Você roda:
tcpdump host X and port 80
E vê:
Só SYN → problema de caminho/firewall
SYN + RST → serviço fora
Handshake completo → problema na aplicação
Lentidão
Procura:
Retransmissão
ACK duplicado
Janela TCP variando muito (win)
Se tem retransmissão, não adianta culpar sistema — é rede.
CGNAT / NAT "zoando conexão"
Você pode ver:
Porta de origem mudando no meio da sessão
RST inesperado
Sessão reiniciando
Muito comum quando tabela NAT tá estourando.
TTL
Mudança brusca → pode indicar roteamento assimétrico
Window Size (win)
Muito baixo → gargalo de recepção
Length
0 = controle
0 = dados
Não olha pacote isolado.
Olha fluxo.
Sempre tenta responder:
Quem iniciou?
Quem respondeu?
Onde parou?
Teve retransmissão?
Se você responder isso, você praticamente já fechou o diagnóstico.
tcpdump não é sobre decorar comando, é sobre saber o que você quer ver e interpretar corretamente.
Se você já entra com:
interface certa
filtro bem definido
e sem poluir saída
você resolve 80% dos problemas só com ele, sem nem precisar abrir Wireshark. Interpretar tcpdump é basicamente entender:
comportamento TCP
padrão vs anomalia
onde o fluxo quebra
Isso aqui, bem treinado, vira uma das habilidades mais fortes pra troubleshooting em ISP e redes de grandes corporações.