Todos os cursos > Tecnologia, Informática e Programação > Servidores Web e Redes de computadores ::

Ferramentas de diagnóstico de rede em servidores: do ping ao traceroute e captura de pacotes

Capítulo 16

Tempo estimado de leitura: 9 minutos

Kit de troubleshooting: ferramentas e quando usar

Em servidores, problemas de rede costumam aparecer como “não consigo acessar X”. Para resolver com rapidez, vale ter um kit de diagnóstico que permita testar, em ordem, conectividade local, caminho até o destino, resolução de nomes, acesso a portas e, quando necessário, observar pacotes reais. A ideia é coletar evidências objetivas (saídas de comandos) e ir eliminando hipóteses por camadas.

Checklist rápido do kit

ICMP: ping (latência/perda), tracepath/traceroute (caminho e MTU).
DNS: dig/nslookup (consulta e tempo de resposta).
Portas/serviços: nc (netcat), curl, openssl s_client (TLS), ss (sockets locais).
Interface e rotas: ip link, ip addr, ip route, ip neigh (ARP/ND), ethtool (link/duplex em NICs Ethernet).
Captura: tcpdump (filtros e análise básica), opcionalmente Wireshark fora do servidor.

Roteiro padrão de diagnóstico (do básico ao avançado)

Use este roteiro como padrão. Em cada etapa, registre o comando e a saída relevante (ou um resumo com timestamps).

1) Confirmar IP/máscara/gateway e estado da interface

Objetivo: garantir que o servidor está “de pé” na rede e com configuração coerente.

# Estado do link e interfaces (UP/DOWN, MTU, etc. )
ip link

# Endereços IP e prefixos configurados
ip addr

# Rotas (inclui rota padrão)
ip route

# Vizinhança L2/L3 (ARP no IPv4, ND no IPv6)
ip neigh

O que observar:

Interface UP e sem erros óbvios (ex.: flaps constantes). Se houver suspeita de camada física/negociação: ethtool eth0.
IP/prefixo esperado na interface correta.
Rota padrão apontando para o gateway correto (ou rotas específicas para a rede do destino).
Neighbor/ARP: entradas REACHABLE/STALE são comuns; FAILED sugere problema na rede local ou no gateway.

2) Testar camada local (alcance do gateway e da LAN)

Objetivo: separar falha local (LAN) de falha “para fora” (roteamento, firewall, etc.).

Continue em nosso aplicativo e ...

Ouça o áudio com a tela desligada
Ganhe Certificado após a conclusão
+ de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

# Ping no gateway (IPv4)
ping -c 4 <IP_DO_GATEWAY>

# Ping em um host conhecido na mesma rede (se existir)
ping -c 4 <IP_LOCAL>

Como interpretar rapidamente:

Sem resposta do gateway: verifique ip neigh (entrada incompleta/FAILED), VLAN errada, cabo/porta, firewall local bloqueando ICMP (menos comum em gateway), ou gateway indisponível.
Perda alta/latência variável na LAN: suspeite de instabilidade de link, duplex/negociação, congestionamento ou problemas físicos.

3) Testar DNS (nome → IP) e isolar falhas de resolução

Objetivo: confirmar se o problema é “não resolve nome” ou “resolve, mas não conecta”. Mesmo quando a aplicação usa nome, sempre teste também por IP para isolar DNS.

# Ver quais resolvers estão configurados
cat /etc/resolv.conf

# Consultar registro A/AAAA e medir tempo
DIG_OPTS="+time=2 +tries=1 +nocmd +noall +answer +stats"
dig $DIG_OPTS exemplo.com A
dig $DIG_OPTS exemplo.com AAAA

# Consultar diretamente um servidor DNS específico (útil para comparar)
dig $DIG_OPTS @<DNS_IP> exemplo.com A

O que observar:

STATUS (NOERROR, NXDOMAIN, SERVFAIL) e tempo de resposta (Query time).
Resposta vazia vs. domínio inexistente (NXDOMAIN).
Diferença entre consultar o resolver padrão e um DNS específico: ajuda a identificar falha no resolver local, no encaminhador (forwarder) ou em regras de firewall.

Dica prática: se por IP funciona e por nome não, foque em DNS (resolvers, reachability até o DNS, regras de firewall para UDP/TCP 53, cache/timeout).

4) Testar rota/caminho até o destino (onde para?)

Objetivo: descobrir até onde o tráfego chega e onde começa a falhar.

# Caminho por UDP/ICMP (depende do sistema e permissões)
traceroute -n <IP_DESTINO>

# Alternativa que também ajuda a indicar MTU (quando disponível)
tracepath <IP_DESTINO>

# Ver qual rota o kernel escolhe para um destino
ip route get <IP_DESTINO>

Como interpretar:

Primeiros saltos ajudam a validar se o tráfego sai pelo gateway esperado.
Asteriscos (*) podem ser apenas roteadores que não respondem a probes; compare com teste de porta (próximo passo) e com captura.
Parada consistente em um salto específico sugere ACL/firewall/roteamento naquele ponto, ou retorno (path de volta) quebrado.

5) Testar porta/aplicação (conectividade TCP/UDP real)

Objetivo: confirmar se o serviço está acessível na porta correta e se o problema é de rede ou da aplicação.

Teste de conexão TCP (handshake)

# Teste simples de TCP (sucesso = "succeeded" / falha = timeout/refused)
nc -vz -w 3 <HOST_OU_IP> 22
nc -vz -w 3 <HOST_OU_IP> 443

# Alternativa com bash (quando nc não está disponível)
timeout 3 bash -c 'cat < /dev/null > /dev/tcp/<HOST_OU_IP>/443' && echo OK || echo FALHOU

Interpretação rápida:

Connection refused: o host respondeu, mas não há serviço escutando na porta (ou firewall local rejeitando ativamente).
Timeout: pode ser firewall no caminho, rota quebrada, serviço travado sem aceitar conexões, ou retorno bloqueado.

Teste HTTP/HTTPS (camada de aplicação)

# HTTP: ver status code e tempo
curl -v --connect-timeout 3 http://<HOST_OU_IP>:80/

# HTTPS: ver handshake, SNI e certificado (diagnóstico)
curl -vk --connect-timeout 3 https://<HOST_OU_IP>:443/

Quando HTTPS falha, diferencie:

Falha antes do TLS (timeout/conexão recusada): problema de rede/porta.
Falha durante TLS (alertas, handshake): pode ser SNI, versão/cifra, certificado, proxy, inspeção TLS.

Verificar sockets locais (no servidor que hospeda o serviço)

# Quem está escutando e em quais endereços/portas
ss -lntup

# Conexões estabelecidas e estados (SYN-SENT, ESTAB, etc.)
ss -antp

O que observar:

LISTEN na porta esperada e em qual IP (0.0.0.0/:: vs. IP específico).
Muitos SYN-RECV pode indicar backlog/ataque/latência no retorno; muitos SYN-SENT no cliente indica que SYN sai mas não volta SYN-ACK.

Captura básica de pacotes (tcpdump): quando e como usar

Quando os testes acima não explicam o problema, a captura mostra o que realmente está acontecendo no fio: se o pacote sai, se há resposta, e em que ponto o fluxo quebra. Em servidores, tcpdump é a ferramenta padrão por ser leve e disponível.

Boas práticas antes de capturar

Capture na interface correta (ex.: eth0, ens192, bond0).
Use filtros para reduzir ruído (host/porta/protocolo).
Inclua timestamps e não resolva nomes durante a captura (evita tráfego extra): -tttt -n.
Se precisar compartilhar com outra equipe, grave em arquivo: -w (pcap).

Comandos práticos de tcpdump

# Captura geral (cuidado: pode gerar muito volume)
sudo tcpdump -i eth0 -n -tttt

# Capturar tráfego com um host específico
sudo tcpdump -i eth0 -n -tttt host <IP_DESTINO>

# Capturar uma porta TCP específica (ex.: 443)
sudo tcpdump -i eth0 -n -tttt tcp port 443 and host <IP_DESTINO>

# Capturar DNS (UDP/TCP 53)
sudo tcpdump -i eth0 -n -tttt port 53

# Gravar em arquivo para análise posterior
sudo tcpdump -i eth0 -n -s 0 -w /tmp/captura.pcap host <IP_DESTINO>

Filtros: conceitos essenciais (BPF)

Os filtros do tcpdump (BPF) permitem selecionar pacotes por IP, porta e flags. Exemplos úteis:

host 10.0.0.10 (origem ou destino)
src host 10.0.0.10 / dst host 10.0.0.10
tcp port 22, udp port 53
net 10.0.0.0/24
tcp[tcpflags] & tcp-syn != 0 (pacotes com SYN)

O que observar: TCP SYN / SYN-ACK na prática

Para diagnosticar “porta não abre”, foque no início do handshake:

Você vê SYN saindo do cliente para o servidor, mas não vê SYN-ACK voltando: o retorno está bloqueado/perdido (firewall no caminho, rota de volta, security group, NAT, assimetria).
Você vê SYN saindo e RST voltando: o host respondeu rejeitando (porta fechada, serviço não escutando, firewall rejeitando).
Você vê SYN e SYN-ACK, mas não completa (sem ACK final): pode ser bloqueio no cliente, problemas de offload/MTU, ou perda no caminho.

Exemplo de captura focada em SYN/SYN-ACK:

# Mostrar apenas tentativas de abertura (SYN) para 443
sudo tcpdump -i eth0 -n -tttt 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)'

O que observar: DNS queries

Em falhas de nome, verifique se o servidor está consultando o DNS e se recebe resposta:

Query sai para o resolver configurado?
Resposta volta (NOERROR/NXDOMAIN/SERVFAIL)?
Há retransmissões (mesma query repetida), indicando perda/bloqueio?
O tráfego DNS está indo para o IP correto (resolver esperado)?

# Capturar e mostrar detalhes de DNS (útil para ver nomes consultados)
sudo tcpdump -i eth0 -n -tttt -vvv port 53

Documentar evidências: padrão mínimo útil

Um troubleshooting eficiente depende de evidência reproduzível. Um padrão simples de documentação (para ticket ou post-mortem) inclui:

Contexto: origem (servidor/IP), destino (host/IP/porta), horário, o que falha e desde quando.
Configuração observada: saída de ip addr, ip route, cat /etc/resolv.conf (remova dados sensíveis se necessário).
Testes e resultados: ping (gateway/destino), dig (com tempos e status), traceroute/tracepath, nc/curl (mensagem de erro).
Capturas: comando usado, período capturado, filtro aplicado, e arquivo pcap (se houver).
Hipótese atual: “SYN sai, SYN-ACK não volta”, “DNS sem resposta do resolver X”, “rota escolhida sai por interface Y”, etc.

Exemplo de roteiro completo (copiar e usar)

Use como sequência padrão quando alguém reportar “não conecta no serviço”:

Identificar alvo: qual HOST, qual IP (se conhecido), qual PORTA, qual protocolo (HTTP/SSH/etc.).
Checar local:
```
ip link; ip addr; ip route; ip neigh
```
Testar gateway:
```
ping -c 4 <GATEWAY>
```

Se for por nome, testar DNS:

dig +time=2 +tries=1 <HOST> A
dig +time=2 +tries=1 <HOST> AAAA

Testar caminho:

ip route get <IP_DESTINO>
traceroute -n <IP_DESTINO>

Testar porta:

nc -vz -w 3 <IP_DESTINO> <PORTA>
# ou curl/openssl conforme o serviço

Se ainda estiver ambíguo, capturar (no cliente e/ou no servidor):

sudo tcpdump -i <IFACE> -n -tttt host <IP_DESTINO> and (port <PORTA> or port 53)

Agora responda o exercício sobre o conteúdo:

Ao diagnosticar “porta não abre” com captura de pacotes, qual cenário indica mais fortemente que o problema está no retorno (path de volta) bloqueado ou perdido?

Você acertou! Parabéns, agora siga para a próxima página

Você errou! Tente novamente.

Se o SYN sai e o SYN-ACK não volta, há forte evidência de que a resposta está sendo bloqueada ou perdida (firewall, rota de volta, assimetria/NAT). Já RST indica rejeição ativa e SYN+SYN-ACK sem ACK final aponta outras causas.