Como debugar problemas de rede no Linux com netstat, ss e tcpdump

Problemas de rede estão entre os desafios mais comuns e frustrantes na administração de sistemas Linux. Conexões lentas, portas que não respondem, pacotes perdidos e timeouts inexplicáveis podem afetar desde um serviço web até uma base de dados crítica. Felizmente, o ecossistema Linux oferece três ferramentas indispensáveis para diagnosticar esses cenários: netstat (o clássico legado), ss (seu sucessor moderno e mais rápido) e tcpdump (a navalha suíça da análise de pacotes). Dominar essas ferramentas permite isolar rapidamente a causa raiz de falhas de conectividade.

Diagnosticando Conexões com netstat

O netstat é a ferramenta tradicional para inspecionar conexões de rede. Embora esteja sendo gradualmente substituído pelo ss, ainda é amplamente disponível e útil.

Para listar todas as portas abertas e serviços escutando:

netstat -tuln

Esse comando exibe conexões TCP (-t) e UDP (-u), mostrando apenas portas em modo escuta (-l) com endereços numéricos (-n). A saída mostra o protocolo, endereço local e estado.

Para ver conexões ativas e seus estados TCP:

netstat -anp

A flag -a mostra todas as conexões, -n evita resolução DNS e -p exibe o PID e nome do processo associado. Isso é essencial para identificar qual programa está usando determinada porta.

netstat -anp | grep :80

Limitações do netstat: ele percorre o diretório /proc de forma menos eficiente que o ss, sendo mais lento em sistemas com muitas conexões. Além disso, alguns estados TCP podem não ser exibidos com precisão.

Análise Avançada com ss (Socket Statistics)

O ss é a alternativa moderna e recomendada, com desempenho superior e filtros mais flexíveis.

Para obter as mesmas informações do netstat:

ss -tuln

Para conexões ativas com detalhes de processos:

ss -anp

Um dos maiores diferenciais do ss é a capacidade de filtrar por estados TCP específicos:

ss state LISTEN
ss state ESTAB
ss state TIME-WAIT

Para monitorar estatísticas gerais de sockets e memória:

ss -s
ss -m

Para debug de conexões com backlog overflow (quando o servidor não consegue aceitar conexões rápido o suficiente):

ss -lnt sport = :80

A coluna Send-Q e Recv-Q indicam filas de envio/recebimento. Valores altos em Recv-Q em sockets LISTEN sugerem backlog saturado.

Captura e Análise de Tráfego com tcpdump

Enquanto netstat e ss mostram o estado atual dos sockets, o tcpdump captura o tráfego real na interface de rede.

Sintaxe básica para capturar pacotes em uma interface:

tcpdump -i eth0

Para capturar tráfego específico com filtros avançados:

tcpdump host 10.0.0.1 and port 443
tcpdump src 192.168.1.100 and tcp port 22

Salvando capturas para análise posterior:

tcpdump -i eth0 -w captura.pcap

Lendo arquivos salvos:

tcpdump -r captura.pcap

A saída do tcpdump mostra timestamps, endereços IP, portas e flags TCP (S para SYN, F para FIN, R para RST, P para PUSH, A para ACK). Por exemplo:

12:34:56.789012 IP 10.0.0.1.54321 > 10.0.0.2.80: Flags [S], seq 1234567890

A flag [S] indica um SYN (início de conexão), [.] é ACK puro, [P.] é push com ACK, e [F.] é fim de conexão.

Correlacionando Dados entre as Ferramentas

O poder real está em combinar as ferramentas. Um fluxo típico de debug:

  1. Identifique portas problemáticas com ss -tuln
  2. Verifique conexões ativas com ss -anp | grep :PORTA
  3. Capture tráfego específico com tcpdump

Exemplo prático: debugando uma conexão SSH lenta.

Primeiro, verifique o estado da conexão:

ss -anp | grep :22

Se houver muitas conexões em TIME_WAIT, pode ser um sinal de cliente reconectando rapidamente. Capture o tráfego para investigar:

tcpdump -i eth0 port 22 -w ssh_trafego.pcap

Após reproduzir o problema, analise com tcpdump -r ssh_trafego.pcap e procure por retransmissões (mesmo pacote aparecendo múltiplas vezes) ou handshakes lentos.

Para monitoramento contínuo, um script simples:

#!/bin/bash
while true; do
    ss -s | grep "TCP:"
    ss state time-wait | wc -l
    sleep 5
done

Solucionando Problemas Comuns com Exemplos Práticos

Porta ocupada ou serviço não responde:

ss -tuln | grep :8080
tcpdump -i eth0 port 8080 -c 10

Se o ss mostra a porta LISTEN mas o tcpdump não vê tráfego, pode ser firewall. Se o tcpdump vê SYN mas não SYN-ACK, o serviço pode estar travado.

Conexões em TIME_WAIT excessivas:

ss state time-wait | wc -l

Milhares de conexões TIME_WAIT podem esgotar portas efêmeras. Solução: ajustar net.ipv4.tcp_fin_timeout ou usar net.ipv4.tcp_tw_reuse.

Perda de pacotes e retransmissões:

tcpdump -i eth0 tcp and port 443

Procure por pacotes com flags [R] (RST) ou sequências duplicadas. O tcpdump mostra [tcp dup ack] para duplicatas e [tcp retransmission] para retransmissões.

Firewall bloqueando tráfego:

tcpdump -i eth0 host 10.0.0.1

Se você vê pacotes saindo (SYN enviado) mas nenhuma resposta, o firewall do destino ou intermediário pode estar bloqueando.

Boas Práticas e Dicas de Performance

Para evitar sobrecarga com tcpdump em redes de alta velocidade:

  • Use filtros específicos: tcpdump -i eth0 port 80 em vez de capturar tudo
  • Aumente o buffer: tcpdump -B 4096 (buffer de 4MB)
  • Salve em disco rápido e use -n para evitar resolução DNS

Automatize diagnósticos com aliases no .bashrc:

alias portlisten='ss -tuln'
alias connstate='ss -anp | grep'
alias cap='tcpdump -i eth0 -n'

Para capturas longas, considere ferramentas como dumpcap (do Wireshark) que gerenciam buffers automaticamente.

Conclusão

Depurar problemas de rede no Linux exige uma abordagem sistemática: use ss para entender o estado das conexões e identificar portas problemáticas, e tcpdump para mergulhar no conteúdo dos pacotes. O netstat ainda é válido em sistemas legados, mas o ss oferece desempenho e flexibilidade superiores.

Lembre-se: conexões em TIME_WAIT indicam encerramentos normais mas excessivos; retransmissões apontam para perda de pacotes; e portas LISTEN sem resposta sugerem firewall ou serviço travado. Combinando essas ferramentas, você pode resolver rapidamente desde problemas simples até falhas complexas de conectividade.

Referências