Troubleshooting de Rede na Prática - Diagnosticando Problemas com ping, traceroute e dig
O Que Você Vai Resolver com Este Artigo
"Não consigo acessar o site." "Só este servidor está inacessível." Falhas de rede são 90% diagnóstico. Com ping, traceroute e dig, você pode sistematicamente restringir o problema verificando alcançabilidade, roteamento e DNS em ordem.
O Padrão de Diagnóstico (3 Passos para Uso Real)
pingpara verificar alcançabilidadetraceroutepara encontrar onde os pacotes paramdigpara verificar resolução DNS
Requisitos de Ambiente
- SO: Ubuntu ou Linux baseado em RHEL
- Acesso CLI disponível
1. ping -- Como Verificar a Alcançabilidade?
ping é a primeira ferramenta para confirmar se os pacotes chegam ao destino. Testar com um endereço IP permite separar problemas de DNS de problemas de roteamento.
$ 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=118 time=8.45 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=7.92 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=8.21 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=8.10 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 7.920/8.170/8.450/0.196 ms
Interpretando a Saída do ping
| Resultado | Significado |
|---|---|
| Respostas recebidas (0% loss) | Conexão física e roteamento estão funcionando |
| 100% packet loss | Problema de roteamento ou firewall bloqueando ICMP |
| Request timeout | Host remoto rejeita ICMP, ou caminho com problema |
Verifique Externo e Interno Separadamente
# Passo 1: Voce alcanca o gateway local? $ ping -c 4 192.168.1.1 # Passo 2: Voce alcanca um DNS do ISP? (confirma conectividade com a internet) $ ping -c 4 8.8.8.8 # Passo 3: Voce consegue pingar por hostname? (confirma que a resolucao DNS funciona) $ ping -c 4 google.com
Se o Passo 2 funcionar mas o Passo 3 falhar, o problema é DNS.
Use -c 4 para limitar o número de pacotes. Sem isso, ping roda indefinidamente até você pressionar Ctrl+C -- sempre use -c em scripts ou verificações rápidas.
2. traceroute -- Onde o Pacote Para?
Quando o destino está inacessível, use traceroute para identificar qual salto está descartando pacotes.
$ 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) 1.234 ms 1.145 ms 1.089 ms 2 10.0.0.1 (10.0.0.1) 8.456 ms 8.512 ms 8.398 ms 3 * * * 4 203.0.113.1 (203.0.113.1) 15.234 ms 15.198 ms 15.321 ms 5 8.8.8.8 (8.8.8.8) 22.567 ms 22.489 ms 22.601 ms
O Que Significa * * *?
* * * significa que aquele roteador não retornou uma mensagem ICMP Time Exceeded. Isso não é necessariamente uma falha. Se os pacotes alcançam saltos além daquele roteador, ele simplesmente está configurado para descartar respostas ICMP.
Quando * * * continua a partir de algum salto e nunca alcanca o destino, os pacotes provavelmente estão sendo descartados naquele ponto ou depois.
Instalando o traceroute
Pode não estar instalado por padrão no Ubuntu:
$ sudo apt install traceroute
mtr é uma alternativa popular que monitora continuamente o caminho e mostra a perda de pacotes por salto em tempo real:
$ sudo apt install mtr $ mtr 8.8.8.8
3. dig -- Como Verificar a Resolução DNS?
Quando você alcanca um endereço IP mas não um hostname, o problema é DNS. Use dig para inspecionar a resolução de nomes em detalhe.
Uso Básico
# Consultar registro A (endereco IPv4) $ dig google.com A # Saida compacta -- apenas a resposta $ dig +short google.com
142.250.196.46
# Consultar um servidor DNS especifico diretamente (isola o servidor DNS) $ dig @8.8.8.8 google.com A
Interpretando a Saída do dig
$ dig google.com A
; <<>> DiG 9.18.18 <<>> google.com A ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 83 IN A 142.250.196.46 ;; Query time: 12 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
- Uma entrada na
ANSWER SECTIONsignifica que a resolução DNS teve sucesso NXDOMAINsignifica que o domínio não existe (ou está digitado errado)SERVFAILsignifica que o servidor DNS falhou em retornar uma resposta
Tipos de Registro DNS e Como Consultar
| Registro | Finalidade | Comando de exemplo |
|---|---|---|
| A | Endereço IPv4 | dig example.com A |
| AAAA | Endereço IPv6 | dig example.com AAAA |
| MX | Servidor de email | dig example.com MX |
| CNAME | Alias | dig example.com CNAME |
| NS | Servidor de nomes | dig example.com NS |
| PTR | Consulta reversa | dig -x 8.8.8.8 |
4. Fluxo de Diagnóstico -- Padrões do Mundo Real
O objetivo é restringir em qual camada a falha está. Siga esta sequência:
Passo 1: O ping para um endereço IP funciona?
$ ping -c 4 8.8.8.8
Se não, é um problema de roteamento L3. Use traceroute para encontrar onde os pacotes param.
Passo 2: O ping para um hostname funciona?
$ ping -c 4 google.com
Se o IP funciona mas o hostname falha, é um problema de DNS. Investigue com dig.
Passo 3: O dig resolve o nome?
$ dig @8.8.8.8 google.com
Se 8.8.8.8 resolve mas seu servidor DNS configurado não, o problema está em /etc/resolv.conf ou no próprio servidor DNS.
Padrões Comuns de Falha e Correções
Padrão 1: Gateway acessível, mas sem acesso à internet
$ ping -c 4 192.168.1.1 # OK $ ping -c 4 8.8.8.8 # Falha
Configuração incorreta do roteador ou problema no ISP. Use traceroute para ver até onde os pacotes viajam.
Padrão 2: IP acessível, mas resolução de hostname falha
$ ping -c 4 8.8.8.8 # OK $ ping -c 4 google.com # Falha
Problema de DNS. Verifique /etc/resolv.conf e tente um servidor DNS alternativo.
$ cat /etc/resolv.conf $ dig @8.8.8.8 google.com $ dig @1.1.1.1 google.com
Padrão 3: Uma porta específica está inacessível
$ ping -c 4 example.com # OK (ICMP funciona) $ curl -v https://example.com # Falha (porta 443 bloqueada)
Problema de firewall. Verifique ufw, firewalld ou iptables.
$ sudo ufw status
ICMP (ping) passando não significa que HTTP/HTTPS passará -- são protocolos diferentes em camadas diferentes. Para conectividade em nível de porta, use nc (netcat) ou curl -v.
5. Quando systemd-resolved Interfere
No Ubuntu 18.04 e posteriores, systemd-resolved atua como intermediário de resolução DNS. Quando dig mostra o servidor como 127.0.0.53, as consultas estão passando pelo systemd-resolved.
# Verificar a configuracao DNS atual $ resolvectl status # Consultar um DNS externo diretamente para comparar $ dig @8.8.8.8 google.com
Se 8.8.8.8 resolve nomes mas 127.0.0.53 não, o problema está na configuração do systemd-resolved ou no symlink de /etc/resolv.conf.
# Verificar para onde /etc/resolv.conf aponta $ ls -la /etc/resolv.conf
O estado normal é /etc/resolv.conf ser um symlink para stub-resolv.conf (gerenciado pelo systemd-resolved). Se aponta para outro lugar ou é um arquivo simples, o comportamento DNS pode ser inesperado.