Troubleshooting de Rede Basico - ping, traceroute, ss, dig

2026-05-30 Tempo de leitura: Cerca de 14 min Dificuldade: Intermediario

O Que Voce Vai Conquistar

• Verificar a conectividade com um host usando ping e controlar a contagem com -c
• Localizar onde o trafego para com traceroute / tracepath
• Verificar portas em escuta e estados de conexao com ss, e explicar sua relacao com netstat
• Verificar configuracoes IP e roteamento com ip addr / ip route
• Isolar sucesso ou falha na resolucao de nomes DNS com dig / host
• Diagnosticar problemas camada por camada, da camada fisica ate DNS e a camada de aplicacao

Este e o nucleo do objetivo 109.3 do LPIC-1 "Resolver problemas basicos de rede". E a habilidade de estreitar "nao conecta" ate uma causa por meio de verificacoes por camada em vez de suposicoes.

Em Que Ordem Voce Deve Isolar as Falhas?

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

Se "um site esta inacessivel", primeiro verifique a conectividade bruta com um IP literal como ping 8.8.8.8, depois verifique a resolucao de nomes com ping example.com. Se o IP funciona mas o dominio nao, voce 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 esta ativo. Use ip addr para confirmar que um endereco IP (inet 192.168.1.20/24) esta atribuido. Se nenhum endereco estiver atribuido, verificar qualquer coisa acima disso nao 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 e o gateway padrao. Sem esta linha voce nao consegue sair da rede local (acessar a internet). A maioria das falhas "a LAN funciona mas nao consigo sair" e 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 apos enviar 4 pacotes" (man ping: "Stop after sending count ECHO_REQUEST packets"). Sem ele, o ping continua enviando ate Ctrl+C. O intervalo e definido com -i em segundos, com padrao 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 ate o destino em ordem (man: "tracks the route packets taken ... on their way to a given host"). Se parar em um salto, tudo ate aquele ponto esta conectado. * * * indica que o salto "nao respondeu dentro do tempo limite"; nao e necessariamente uma falha, pois roteadores que nao retornam ICMP tambem mostram isso.

Para executar como usuario sem privilegios, ou para tambem 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 basica e dig @servidor nome tipo (oficial BIND 9). Se a ANSWER SECTION mostrar um resultado (um registro de recurso), a resolucao de nomes foi bem-sucedida. +short fornece saida 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 e um utilitario de consulta DNS mais simples; host nome sozinho reporta A, AAAA e MX juntos.

Passo 6: Verificar portas em escuta e conexoes 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 estatisticas de sockets. O significado da combinacao comum -tulnp, conforme man ss, e o seguinte.

Quando "iniciei um servico mas nao consigo conectar", use ss -tlnp para verificar se a porta alvo esta em LISTEN e qual processo a ocupa.

Por Que Usar ss em Vez de netstat?

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

Na pratica, ss e mais rapido que netstat; ele obtem informacoes de socket diretamente do kernel em vez de ler /proc/net. Seu esquema de opcoes e altamente compativel, entao netstat -tulnp se traduz quase diretamente para ss -tulnp. Runbooks antigos ainda carregam netstat, mas em sistemas novos ss e a primeira escolha padrao. A correspondencia (ss sucede netstat, ip route sucede route / netstat -r) tambem e um ponto frequente no exame LPIC-1.

Erros Comuns

• Parar porque assume que netstat existe: Containers minimos e distros mais novas podem nao incluir netstat (net-tools). Conhecer ss permite trabalhar sem instalacao extra.
• Concluir "fora do ar" a partir de uma falha no ping: Em ambientes que bloqueiam ICMP, o ping falha mesmo quando tudo esta funcionando. Avalie junto com a acessibilidade de portas TCP (via ss / verificacoes na camada de aplicacao).
• Confundir uma falha de DNS com uma falha de conectividade: Nao conclua "a rede esta 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 fisica, IP e roteamento estao bem e a causa e DNS.
• Nao perceber a ausencia do gateway padrao: Quando a LAN funciona mas voce nao consegue sair, ip route frequentemente nao tem uma linha default via .... Nao pare apos verificar apenas o endereco.
• Leitura errada de portas do ss por resolucao de nomes: Sem -n, :22 aparece como :ssh, tornando a identificacao de portas mais lenta. Adicione -n ao verificar.

Solucao de Problemas

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

Causa: A rede esta bem, mas a resolucao de nomes DNS esta falhando

Verificacao:

ping -c 2 8.8.8.8
dig +short example.com

Solucao: Se o ping com IP literal funciona, as camadas fisica, IP e roteamento estao bem. Se dig nao consegue resolver, verifique a linha nameserver em /etc/resolv.conf e configure um servidor DNS acessivel.

Sintoma: A LAN funciona mas a internet esta inacessivel

Causa: O gateway padrao esta ausente ou errado

Verificacao:

ip route show
ping -c 2 192.168.1.1

Solucao: 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 configuracao da distro).

Sintoma: Um servico foi iniciado mas os clientes nao conseguem conectar

Causa: O processo nao esta escutando no endereco/porta pretendido, ou um firewall esta bloqueando

Verificacao:

ss -tlnp

Solucao: Confirme que a porta alvo esta em LISTEN e que o endereco de escuta nao e 127.0.0.1 (somente local) mas algo como 0.0.0.0. Se esta em LISTEN, a aplicacao esta bem e a causa provavelmente esta do lado do firewall.

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

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

Verificacao:

traceroute 8.8.8.8
tracepath 8.8.8.8

Solucao: Mesmo com * * *, se o rastreamento alcanca o destino com uma resposta na linha final, a rota esta viva (o roteador intermediario apenas nao retorna ICMP). Se nunca alcanca o salto final, voce pode estreitar a falha para alem do ultimo salto que respondeu.

Lista de Verificacao de Conclusao

• [ ] Verificou a interface e o IP com ip addr / ip link
• [ ] Verificou o gateway padrao 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 resolucao de nomes DNS com dig / host
• [ ] Verificou portas em escuta e processos com ss -tulnp

Resumo

A essencia do troubleshooting de rede e "eliminar camadas em ordem". Verificar de baixo para cima permite alcancar a causa sem depender de intuicao. Combine isso com saber que netstat e substituido por ss e ifconfig/route por ip, e voce cobre o objetivo 109.3 de ponta a ponta.

Proximas Leituras

• Fundamentos de Protocolos de Internet
• Configuracao Basica de Rede
• Configuracao de Cliente DNS