TCPDUMP

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.

1. Interface e endereçamento (começa sempre por aqui)

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.

2. Protocolos e lógica (onde começa a ficar útil de verdade)

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.

3. Flags TCP (isso aqui entrega MUITA coisa)

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.

4. Olhando payload (quando precisa ir mais fundo)

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).

5. Salvando captura (pra analisar direito depois)

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.

6. Performance (isso aqui é obrigatório, não opcional)

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.

7. Interpretação dos logs (o que realmente importa)

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.

Estrutura básica de um log

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.

Fluxo normal TCP (3-way handshake)

O padrão esperado:

1. [SYN]     Cliente → Servidor

2. [SYN,ACK] Servidor → Cliente

3. [ACK]     Cliente → Servidor

Na prática no tcpdump:

1. Client > Server: Flags [S]

2. Server > Client: Flags [S.]

3. Client > Server: Flags [.]

Se isso não fecha, já tem problema.

Problemas comuns (e como identificar)

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

Casos clássicos de troubleshooting (vida real)

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.

Detalhes que pouca gente presta atenção

• TTL

  • Mudança brusca → pode indicar roteamento assimétrico

• Window Size (win)

  • Muito baixo → gargalo de recepção

• Length

  • 0 = controle

  • 0 = dados

Dica de ouro

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.

Conclusão:

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.