Troubleshooting de Rede Básico - ping, traceroute, ss, dig

2026-05-30 Tempo de leitura: Cerca de 14 min Dificuldade: Intermediário

O Que Você Vai Conquistar

• Verificar a conectividade com um host usando ping e controlar a contagem com -c
• Localizar onde o tráfego para com traceroute / tracepath
• Verificar portas em escuta e estados de conexão com ss, e explicar sua relação com netstat
• Verificar configurações IP e roteamento com ip addr / ip route
• Isolar sucesso ou falha na resolução de nomes DNS com dig / host
• Diagnosticar problemas camada por camada, da camada física até DNS e a camada de aplicação

Este é o núcleo do objetivo 109.3 do LPIC-1 "Resolver problemas básicos de rede". É a habilidade de estreitar "não conecta" até uma causa por meio de verificações por camada em vez de suposições.

Em Que Ordem Você Deve Isolar as Falhas?

Falhas de rede são diagnosticadas mais rapidamente quando se verifica das camadas inferiores para as superiores. Se uma camada inferior estiver quebrada, as camadas acima sempre falham, então eliminar falhas de baixo para cima é a regra.

Se "um site está inacessível", primeiro verifique a conectividade bruta com um IP literal como ping 8.8.8.8, depois verifique a resolução de nomes com ping example.com. Se o IP funciona mas o domínio não, você isolou o problema no DNS em um passo.

Passo a Passo

Passo 1: Verificar a interface e o IP

ip link show
ip addr show

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    link/ether 08:00:27:ab:cd:ef brd ff:ff:ff:ff:ff:ff
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    inet 192.168.1.20/24 brd 192.168.1.255 scope global enp0s3

ip link mostra o estado dos dispositivos de rede (camada de enlace). Se UP e LOWER_UP estiverem presentes, o enlace está ativo. Use ip addr para confirmar que um endereço IP (inet 192.168.1.20/24) está atribuído. Se nenhum endereço estiver atribuído, verificar qualquer coisa acima disso não faz sentido.

Passo 2: Verificar roteamento e o gateway

ip route show

default via 192.168.1.1 dev enp0s3 proto dhcp metric 100
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.20

ip route mostra a tabela de roteamento. default via 192.168.1.1 é o gateway padrão. Sem esta linha você não consegue sair da rede local (acessar a internet). A maioria das falhas "a LAN funciona mas não consigo sair" é causada exatamente aqui.

Passo 3: Verificar conectividade com ping

ping -c 4 192.168.1.1
ping -c 4 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=11.8 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms

ping verifica a conectividade com pacotes ICMP ECHO. -c 4 significa "parar após enviar 4 pacotes" (man ping: "Stop after sending count ECHO_REQUEST packets"). Sem ele, o ping continua enviando até Ctrl+C. O intervalo é definido com -i em segundos, com padrão de 1 segundo. Verifique o gateway primeiro, depois um IP externo.

Passo 4: Rastrear a rota com traceroute

traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.8 ms  0.7 ms  0.7 ms
 2  10.0.0.1 (10.0.0.1)  8.2 ms  8.1 ms  8.0 ms
 3  * * *
 4  8.8.8.8 (8.8.8.8)  12.1 ms  12.0 ms  11.9 ms

traceroute mostra cada salto (roteador) ao longo da rota até o destino em ordem (man: "tracks the route packets taken ... on their way to a given host"). Se parar em um salto, tudo até aquele ponto está conectado. * * * indica que o salto "não respondeu dentro do tempo limite"; não é necessariamente uma falha, pois roteadores que não retornam ICMP também mostram isso.

Para executar como usuário sem privilégios, ou para também descobrir o MTU do caminho, use tracepath. Conforme man tracepath, "tracepath is not a privileged program, unlike traceroute".

tracepath example.com

Passo 5: Verificar DNS com dig / host

dig example.com
dig +short example.com

;; ANSWER SECTION:
example.com.		3600	IN	A	93.184.216.34

93.184.216.34

dig mostra os detalhes de uma consulta DNS. A sintaxe básica é dig @servidor nome tipo (oficial BIND 9). Se a ANSWER SECTION mostrar um resultado (um registro de recurso), a resolução de nomes foi bem-sucedida. +short fornece saída resumida, retornando apenas o valor.

dig MX example.com
dig -x 93.184.216.34
host example.com

Para especificar um tipo de registro, adicione o tipo (dig MX example.com). -x realiza uma consulta reversa (PTR) de um IP para um hostname. host é um utilitário de consulta DNS mais simples; host nome sozinho reporta A, AAAA e MX juntos.

Passo 6: Verificar portas em escuta e conexões com ss

ss -tulnp

Netid State   Local Address:Port   Peer Address:Port  Process
tcp   LISTEN  0.0.0.0:22           0.0.0.0:*          users:(("sshd",pid=812,fd=3))
tcp   LISTEN  0.0.0.0:80           0.0.0.0:*          users:(("nginx",pid=940,fd=6))
udp   UNCONN  0.0.0.0:68           0.0.0.0:*

ss mostra estatísticas de sockets. O significado da combinação comum -tulnp, conforme man ss, é o seguinte.

Quando "iniciei um serviço mas não consigo conectar", use ss -tlnp para verificar se a porta alvo está em LISTEN e qual processo a ocupa.

Por Que Usar ss em Vez de netstat?

A seção NOTES da man page do netstat afirma claramente: "This program is mostly obsolete. Replacement for netstat is ss." Em outras palavras, ss é oficialmente posicionado como seu sucessor. Da mesma forma, a man page diz que o substituto para netstat -r é ip route, e o substituto para netstat -i é ip -s link.

Na prática, ss é mais rápido que netstat; ele obtém informações de socket diretamente do kernel em vez de ler /proc/net. Seu esquema de opções é altamente compatível, então netstat -tulnp se traduz quase diretamente para ss -tulnp. Runbooks antigos ainda carregam netstat, mas em sistemas novos ss é a primeira escolha padrão. A correspondência (ss sucede netstat, ip route sucede route / netstat -r) também é um ponto frequente no exame LPIC-1.

Erros Comuns

• Parar porque assume que netstat existe: Containers mínimos e distros mais novas podem não incluir netstat (net-tools). Conhecer ss permite trabalhar sem instalação extra.
• Concluir "fora do ar" a partir de uma falha no ping: Em ambientes que bloqueiam ICMP, o ping falha mesmo quando tudo está funcionando. Avalie junto com a acessibilidade de portas TCP (via ss / verificações na camada de aplicação).
• Confundir uma falha de DNS com uma falha de conectividade: Não conclua "a rede está fora do ar" apenas a partir de uma falha em ping nome-dominio. Se um IP literal (ping 8.8.8.8) funciona, as camadas física, IP e roteamento estão bem e a causa é DNS.
• Não perceber a ausência do gateway padrão: Quando a LAN funciona mas você não consegue sair, ip route frequentemente não tem uma linha default via .... Não pare após verificar apenas o endereço.
• Leitura errada de portas do ss por resolução de nomes: Sem -n, :22 aparece como :ssh, tornando a identificação de portas mais lenta. Adicione -n ao verificar.

Solução de Problemas

Sintoma: ping example.com falha com Name or service not known

Causa: A rede está bem, mas a resolução de nomes DNS está falhando

Verificação:

ping -c 2 8.8.8.8
dig +short example.com

Solução: Se o ping com IP literal funciona, as camadas física, IP e roteamento estão bem. Se dig não consegue resolver, verifique a linha nameserver em /etc/resolv.conf e configure um servidor DNS acessível.

Sintoma: A LAN funciona mas a internet está inacessível

Causa: O gateway padrão está ausente ou errado

Verificação:

ip route show
ping -c 2 192.168.1.1

Solução: Confirme que ip route tem uma linha default via <IP do gateway>. Se estiver ausente, adicione com ip route add default via <IP do gateway> (torne persistente via arquivo de configuração da distro).

Sintoma: Um serviço foi iniciado mas os clientes não conseguem conectar

Causa: O processo não está escutando no endereço/porta pretendido, ou um firewall está bloqueando

Verificação:

ss -tlnp

Solução: Confirme que a porta alvo está em LISTEN e que o endereço de escuta não é 127.0.0.1 (somente local) mas algo como 0.0.0.0. Se está em LISTEN, a aplicação está bem e a causa provavelmente está do lado do firewall.

Sintoma: traceroute para em * * * no meio do caminho

Causa: Um roteador ao longo do caminho não retorna ICMP, ou a rota realmente quebra ali

Verificação:

traceroute 8.8.8.8
tracepath 8.8.8.8

Solução: Mesmo com * * *, se o rastreamento alcança o destino com uma resposta na linha final, a rota está viva (o roteador intermediário apenas não retorna ICMP). Se nunca alcança o salto final, você pode estreitar a falha para além do último salto que respondeu.

Lista de Verificação de Conclusão

• [ ] Verificou a interface e o IP com ip addr / ip link
• [ ] Verificou o gateway padrão com ip route
• [ ] Verificou a conectividade com o gateway e um IP externo com ping -c
• [ ] Verificou onde a rota para com traceroute / tracepath
• [ ] Verificou a resolução de nomes DNS com dig / host
• [ ] Verificou portas em escuta e processos com ss -tulnp

Resumo

A essência do troubleshooting de rede é "eliminar camadas em ordem". Verificar de baixo para cima permite alcançar a causa sem depender de intuição. Combine isso com saber que netstat é substituído por ss e ifconfig/route por ip, e você cobre o objetivo 109.3 de ponta a ponta.

Próximas Leituras

• Fundamentos de Protocolos de Internet
• Configuração Básica de Rede
• Configuração de Cliente DNS