Diagnóstico de rede no Linux: do cabo ao DNS

Diagnóstico de rede sem adivinhação

Quando a rede falha, evite começar por comandos aleatórios. Siga o caminho que os pacotes percorrem: primeiro a própria máquina, depois o roteador, a internet, o DNS e, por fim, o serviço específico.

Antes de começar: substitua os endereços de exemplo pelos valores da sua rede. Os testes abaixo são voltados para máquinas e redes que você administra ou tem autorização para verificar.

1. A interface recebeu um endereço?

O comando ip é o ponto de partida nas distribuições atuais. Ele mostra interfaces, estado do link e endereços atribuídos.

ip addr

Procure uma interface como enp3s0, eth0 ou wlan0. Ela deve aparecer como UP e possuir um endereço inet, por exemplo 192.168.1.20/24.

Para uma visão mais compacta:

ip -br addr

Como interpretar:

- UP indica que a interface está habilitada;
- inet é o endereço IPv4;
- inet6 é o endereço IPv6;
- DOWN ou ausência de endereço aponta para link, Wi-Fi, DHCP ou configuração local.

Se o endereço foi obtido por DHCP, também vale consultar o estado do gerenciador de rede:

nmcli device status

Dica: se a interface estiver DOWN, teste o cabo ou a conexão Wi-Fi antes de mexer em DNS. Um problema físico não é corrigido por configuração de nomes.

2. Existe uma rota para sair da máquina?

O próximo salto normalmente é o roteador da rede local. Veja a tabela de rotas:

ip route

Você deve encontrar uma linha parecida com:

default via 192.168.1.1 dev enp3s0

O endereço depois de default via é o gateway padrão. Para consultar diretamente qual rota seria usada para um destino:

ip route get 1.1.1.1

Esse comando mostra a interface, o endereço de origem e o próximo salto escolhidos pelo kernel.

3. O computador alcança o gateway?

Teste primeiro o equipamento mais próximo, normalmente o roteador:

ping -c 4 192.168.1.1

O parâmetro -c 4 limita o teste a quatro pacotes. Observe o tempo de resposta e a perda. Se o gateway não responder, investigue interface, cabo, Wi-Fi, VLAN ou DHCP antes de testar a internet.

Alguns roteadores bloqueiam ICMP. Nesse caso, a ausência de resposta não prova sozinha que o gateway está desligado; combine o teste com ip addr, ip route e uma tentativa autorizada em uma porta conhecida.

4. Há conectividade com a internet?

Agora teste um endereço IP externo, sem envolver DNS:

ping -c 4 1.1.1.1

Se o gateway responde e esse teste falha, verifique rota de saída, firewall, NAT ou a conexão do provedor. Se o IP externo responde, mas nomes não funcionam, avance para a etapa de DNS.

Para medir o caminho sem deixar o ping rodando indefinidamente, use -c. Pressione Ctrl + C apenas quando estiver usando o modo contínuo sem essa opção.

5. O DNS está resolvendo nomes?

Teste a resolução com resolvectl, quando disponível:

resolvectl query example.com

Outra opção é o dig, que mostra mais detalhes da consulta:

dig example.com

Para comparar com um resolvedor público específico:

dig @1.1.1.1 example.com

Leitura rápida:

- resposta com ANSWER SECTION: o servidor retornou um registro;
- SERVFAIL: o resolvedor não conseguiu concluir a consulta;
- NXDOMAIN: o nome consultado não existe;
- timeout: pode haver problema de rota, firewall ou servidor DNS.

Se dig @1.1.1.1 funcionar e a consulta padrão não, compare a configuração de DNS do sistema e da rede.

6. Por onde os pacotes estão passando?

Quando há perda ou lentidão entre sua máquina e um destino, rastreie os saltos:

tracepath example.com

Em sistemas que possuem o pacote instalado, também é possível usar:

traceroute example.com

O resultado ajuda a localizar em qual trecho a latência aumenta. Um * isolado não significa necessariamente falha: alguns roteadores simplesmente não respondem a esse tipo de consulta. Compare horários e destinos antes de concluir.

7. O serviço está escutando localmente?

Para investigar uma aplicação que deveria atender em uma porta, liste sockets em escuta:

ss -tulpn

Filtros úteis:

ss -ltnp | grep :22

ss -ltnp | grep :443

As opções mais comuns são -t para TCP, -u para UDP, -l para listening e -p para processo. Dependendo da distribuição, pode ser necessário sudo para visualizar o nome de todos os processos.

Se nada estiver escutando, o problema está no serviço ou na configuração local — não no DNS.

8. Uma porta específica está acessível?

Para testar uma porta TCP de um host que você administra:

nc -zv 192.168.1.10 22

O modo -z testa sem enviar dados e -v mostra detalhes. Use esse teste somente em destinos autorizados e prefira uma porta de serviço que você espera encontrar aberta.

Resultado de conexão recusada geralmente indica que o host respondeu, mas não há serviço aceitando naquela porta. Timeout pode apontar para firewall, rota ou host indisponível.

9. Mapeamento autorizado com nmap

Em uma rede própria ou laboratório, o nmap pode confirmar portas específicas:

nmap -p 22,80,443 192.168.1.10

Para descobrir quais hosts respondem em uma sub-rede sob sua administração:

nmap -sn 192.168.1.0/24

Não faça varreduras em redes de terceiros. Em ambientes corporativos, combine o teste com a política de segurança e a janela de manutenção.

Fluxo rápido para guardar

1. ip -br addr — a interface tem endereço?
2. ip route — existe gateway padrão?
3. ping -c 4 GATEWAY — a rede local responde?
4. ping -c 4 1.1.1.1 — há saída para a internet?
5. dig example.com — o DNS funciona?
6. tracepath example.com — onde a rota fica lenta?
7. ss -ltnp — o serviço está escutando?

Conclusão
Registre os resultados de cada etapa. A primeira etapa que falhar normalmente indica o lugar certo para continuar investigando, tornando o diagnóstico mais rápido, seguro e reproduzível.