Módulo 08

Troubleshooting de Redes

Como diagnosticar problemas de rede sistematicamente: a metodologia, os comandos e como interpretar cada resultado.

Progresso0%

A Metodologia — Como Pensar

📖 Diagnose de dentro para fora

Quando a rede "não funciona", a maioria das pessoas fica tentando coisas aleatórias. Profissionais seguem uma metodologia: eliminam possibilidades de forma sistemática, do ponto mais próximo ao mais distante.

Ordem de diagnóstico (bottom-up pelo OSI):

  1. Físico: o cabo está conectado? O Wi-Fi está ativo? A interface está UP? Parece óbvio, mas 30% dos problemas são físicos.
  2. Enlace/Local: ping para o gateway (192.168.1.1). Se funciona, sua rede local está ok.
  3. Internet (IP): ping para um IP na internet (8.8.8.8). Se funciona, mas DNS não, o problema é de resolução de nomes.
  4. DNS: nslookup google.com. Se IP funciona mas nome não, é problema de DNS.
  5. Aplicação: ping funciona mas site não carrega? Pode ser porta bloqueada, firewall, ou problema no servidor.
⚡ Regra de ouro do troubleshooting

"O que mudou?" — A pergunta mais importante. A rede funcionava antes? O que foi alterado recentemente? Updates de sistema? Novo roteador? Mudança de ISP? 80% dos problemas novos têm uma causa recente identificável.

ping — Testando Conectividade

📖 O que é e como usar

O ping envia pacotes ICMP Echo Request para um destino e aguarda ICMP Echo Reply. Mede o RTT (Round-Trip Time) e detecta perda de pacotes.

# Linux / Mac
ping -c 5 8.8.8.8

# Windows
ping -n 5 8.8.8.8

Saída típica:

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=12.4 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=11.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=13.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=12.5 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=12.2 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss
round-trip min/avg/max/stddev = 11.9/12.4/13.1/0.4 ms
🔍 Como interpretar
  • time=12.4 ms: latência (RTT). Abaixo de 50ms é bom para internet doméstica.
  • ttl=117: TTL (Time To Live). O valor original era 128 (Windows) ou 64 (Linux). 128-117=11 hops até o destino.
  • 0% packet loss: sem perda de pacotes. Qualquer perda acima de 1% em conexão estável indica problema.
  • stddev=0.4 ms: desvio padrão da latência (jitter). Baixo = conexão estável.

Sequência de diagnóstico com ping:

  1. ping 127.0.0.1 — testa o próprio stack de rede do SO. Se falhar, problema no SO.
  2. ping 192.168.1.1 — testa conectividade com o gateway. Se falhar, problema na rede local.
  3. ping 8.8.8.8 — testa conectividade internet. Se falhar, problema de roteamento/ISP.
  4. ping google.com — testa DNS. Se falhar aqui mas IP funcionar, problema de DNS.
Sintomas típicos
  • site lento ou indisponível
  • VPN conecta mas fica instável
  • perda intermitente em chamadas
O que o ping prova

Prova que existe retorno ICMP naquele caminho e permite medir latência/perda básica.

O que ele não prova

Não prova que a aplicação está saudável. Um host pode responder ao ping e ainda falhar em HTTPS, SSH ou DNS.

Decisão seguinte

Se o IP responde mas o serviço não, avance para porta, DNS ou aplicação. Se nem o gateway responde, volte para a rede local.

traceroute / tracert — Rastreando o Caminho

📖 Como funciona

O traceroute revela cada roteador (hop) no caminho entre você e o destino, com a latência de cada salto. Funciona enviando pacotes com TTL crescente: primeiro TTL=1 (morre no primeiro roteador, que responde com ICMP Time Exceeded), depois TTL=2, etc.

# Linux / Mac
traceroute google.com

# Windows
tracert google.com

Saída típica:

traceroute to google.com (142.250.78.14), 30 hops max
 1  192.168.1.1 (192.168.1.1)     1.2 ms   1.1 ms   1.0 ms   ← Gateway local
 2  10.10.0.1 (10.10.0.1)         8.4 ms   8.5 ms   8.3 ms   ← Roteador do ISP
 3  200.45.12.1                   12.3 ms  12.1 ms  12.4 ms  ← POP do ISP
 4  * * *                         timeout  timeout  timeout  ← Bloqueia ICMP
 5  108.170.236.1                  22.5 ms  22.3 ms  22.6 ms
 6  142.250.78.14                  24.8 ms  24.5 ms  24.9 ms  ← Google!
🔍 Como interpretar
  • Latência crescendo gradualmente: normal — cada hop adiciona tempo de processamento e distância física.
  • Latência pulando muito em um hop específico: gargalo naquele roteador.
  • "* * *": não significa que a rota parou — muitos roteadores bloqueiam ICMP. Se o destino final responde, a rota está ok.
  • Rota para quando a latência aumenta abruptamente: indica congestionamento ou problema naquele segmento.
Sintomas típicos
  • lentidão só para destinos externos
  • tráfego degradado após certos horários
  • suspeita de gargalo fora da LAN
O que o traceroute prova

Prova por onde o pacote passou e em que salto a latência mudou de padrão.

O que ele não prova

Não prova que o hop marcado com `* * *` esteja quebrado. Muitos roteadores só deixam de responder ICMP.

Decisão seguinte

Se a degradação começa fora da empresa, pare de culpar o Wi-Fi local e compare com outro destino ou outro provedor.

nslookup — Depurando DNS

📖 Consultas DNS manuais
# Consulta básica
nslookup google.com

# Especificar servidor DNS
nslookup google.com 8.8.8.8

# Consultar registro específico (MX, TXT, AAAA)
nslookup -type=MX gmail.com
nslookup -type=TXT github.com
nslookup -type=AAAA google.com

Saída típica:

Server:  192.168.1.1    ← DNS sendo consultado
Address: 192.168.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.78.14  ← IP resolvido

"Non-authoritative answer" significa que a resposta veio de um cache (não diretamente do servidor autoritativo). É normal.

Cenários de diagnóstico:

  • "Can't resolve": o DNS não conseguiu resolver. Tente com 8.8.8.8 explicitamente — se funcionar, o problema é no seu servidor DNS padrão.
  • IP errado: propagação DNS incompleta, ou cache corrompido. Limpe o cache com ipconfig /flushdns (Windows) ou sudo systemd-resolve --flush-caches (Linux).
  • SERVFAIL: o servidor DNS tentou resolver mas falhou.
  • NXDOMAIN: o domínio não existe.
Sintomas típicos
  • IP funciona, nome falha
  • algumas máquinas resolvem certo e outras não
  • site abre por IP, mas não por domínio
O que o nslookup prova

Prova qual servidor DNS respondeu e qual IP ou erro foi devolvido para aquele nome.

O que ele não prova

Não prova que a aplicação final esteja boa. DNS pode resolver certo e o serviço ainda falhar por porta, TLS ou rota.

Decisão seguinte

Se o nome resolve errado, teste outro DNS e cache. Se resolve certo, avance para `curl`, navegador ou teste de porta.

netstat — Conexões Ativas

📖 O que mostra

O netstat (ou o moderno ss no Linux) mostra conexões TCP/UDP ativas, portas em escuta (LISTEN) e estatísticas de rede.

# Conexões ativas com processo
netstat -tulnp      # Linux (com sudo para ver processos)
netstat -ano        # Windows

# Ver quem está escutando em uma porta específica
ss -tlnp | grep :80  # Linux moderno

Saída e estados TCP:

  • LISTEN: serviço aguardando conexões naquela porta
  • ESTABLISHED: conexão ativa
  • TIME_WAIT: conexão encerrada, aguardando timeout (normal)
  • CLOSE_WAIT: conexão remota fechou, aguardando local fechar
  • SYN_SENT: tentando estabelecer conexão

Use netstat para: verificar se um serviço está realmente escutando na porta esperada, ver conexões suspeitas (processo desconhecido com conexão externa), diagnosticar "port in use" ao subir um serviço.

Sintomas típicos
  • porta parece fechada
  • serviço não sobe porque a porta já está em uso
  • conexões estranhas saindo da máquina
O que o netstat prova

Prova que existe um processo escutando ou que houve uma conexão TCP em determinado estado.

O que ele não prova

Não prova que clientes externos conseguem chegar ali. A porta pode estar em LISTEN e ainda ser bloqueada por firewall ou ACL.

Decisão seguinte

Se a porta está em LISTEN, teste a conectividade do ponto de vista do cliente. Se não está, o problema é processo ou configuração local.

Fluxograma de Diagnóstico

Diagnóstico: "Não consigo acessar a internet"

Início: Rede não funciona
↓
ping 127.0.0.1
↓
Falha → Stack TCP/IP corrompido
Reinstale drivers de rede
FALHA
←
OK?
→
OK → Continua
OK
↓
ping 192.168.1.1 (gateway)
↓
Falha → Cabo/Wi-Fi
Verifique conexão física
Reinicie roteador
FALHA
←
OK?
→
OK → Continua
OK
↓
ping 8.8.8.8 (IP externo)
↓
Falha → Problema no ISP
Verifique pagamento/status
Ligue para suporte
FALHA
←
OK?
→
OK → Continua
OK
↓
nslookup google.com
↓
Falha → Problema de DNS
Mude para 8.8.8.8 ou 1.1.1.1
ipconfig /flushdns
FALHA
←
OK?
→
DNS OK mas site falha →
Problema na aplicação
Verifique porta/firewall
OK

🃏 Flashcards — Troubleshooting

1 / 6
Clique para ver a resposta
Resposta

📝 Quiz — Troubleshooting