Por que resolução de problemas de rede exige uma ordem — e como o fluxo do físico ao lógico é a diferença entre quem resolve e quem fica tentando.

Era quarta-feira de manhã. Reunião de diretoria, 40 pessoas, videoconferência com escritório em São Paulo.

A chamada travou. O áudio ficou robótico, as imagens congelaram, o chat encheu de “alguém me ouve?” e “meu lado está ok”.

O estagiário de TI no andar de cima — três semanas no cargo — foi direto ao roteador. Desligou. Esperou. Ligou. Esperou dois minutos. A chamada continuou travando.

Desligou de novo. Esperou mais. Ligou. Esperou.

Nada.

O técnico sênior chegou sete minutos depois. Não tocou no roteador. Abriu o prompt de comando no notebook mais próximo, digitou ipconfig, olhou para a tela por três segundos, e disse:

— O switch do terceiro andar está com port flapping no trunk. O roteador não tem nada a ver com isso.

Dois minutos depois, ele havia movido o cabo para outra porta do switch. A reunião voltou.

O roteador nunca foi o problema.

Troubleshooting de rede é a disciplina onde a diferença entre profissional e amador fica mais evidente. Não porque os problemas sejam especialmente difíceis — mas porque a tentação de ir direto à solução antes de entender o problema é enorme, e redes têm muitas camadas onde as coisas podem falhar.

Este post cobre o Objetivo 5.5 do CompTIA A+ Core 1 (220-1201 V15): dado um cenário, diagnosticar problemas de rede. São dez sintomas distintos no documento oficial, e cada um tem uma lógica de investigação.

A estrutura que vamos usar é a mesma do técnico sênior da história: do físico ao lógico. Você começa no cabo. Termina na aplicação.

PARTE 1 — O FLUXO BASE: ANTES DE TUDO, OUÇA A REDE

Antes de executar qualquer comando ou mover qualquer cabo, dois segundos de observação valem mais do que cinco minutos de tentativa e erro.

Verifique o link light. Toda interface de rede tem uma luz indicadora. Se o cabo está conectado e a luz não acende, você não tem conectividade física — e não adianta ir para diagnóstico lógico ainda. Se a luz pisca irregularmente (acende, apaga, acende, apaga em ciclo rápido), você provavelmente tem port flapping.

Verifique onde o problema está isolado. Um único usuário sem acesso à internet é diferente de todo um andar sem acesso. Todos os dispositivos no mesmo switch não conseguem acessar o servidor de arquivos é diferente de um notebook específico que não consegue autenticar. A amplitude do problema já diz muito sobre a camada afetada.

Execute ipconfig (Windows) ou ip addr (Linux). O endereço IP que aparece aqui é o diagnóstico mais rápido disponível. Ele resolve a maioria dos casos de “sem internet” em menos de 30 segundos — se você souber o que está olhando.

PARTE 2 — OS DEZ SINTOMAS DO OBJETIVO 5.5

1. Port Flapping

O que é: A interface de rede sobe e cai em ciclo rápido — link light pisca, conexão cai, volta, cai de novo. Em um switch gerenciado, os logs mostram o evento repetidamente.

Por que acontece: Problema físico na maioria dos casos. Cabo danificado, conector RJ45 mal crimpado, porta do switch com defeito, transceiver SFP com mau contato. Em casos menos comuns, incompatibilidade de duplex (full duplex vs. half duplex) entre dois dispositivos.

Como diagnosticar:

• Verifique fisicamente o cabo — substitua por um que você sabe que funciona
• Mova o cabo para outra porta do switch — se o port flapping acompanhar o cabo, o problema é o cabo; se ficar na porta, o problema é a porta
• Em switches gerenciados, verifique os logs de erro da interface
• Confirme se o duplex está configurado corretamente em ambos os lados

Erro mais comum: reiniciar o roteador. Port flapping é um problema de camada 1 (física) ou no máximo camada 2 (enlace). O roteador fica na camada 3. Reiniciá-lo não resolve nada.

2. Intermittent Wireless Connectivity

O que é: A conexão Wi-Fi aparece e desaparece sem ação do usuário. Diferente do port flapping, que é previsível e rápido, a conectividade wireless intermitente pode demorar minutos ou horas entre quedas.

Por que acontece: Interferência de outros dispositivos na mesma frequência, sobreposição de canais entre access points vizinhos, sinal fraco na borda de cobertura, ou o dispositivo trocando de access point em ambientes com múltiplos APs (roaming). Em empresas com controladora wireless, pode ser problema de configuração de handoff.

Como diagnosticar:

• Verifique o RSSI (Received Signal Strength Indicator) no dispositivo — sinal fraco na borda da cobertura é o suspeito mais comum
• Use um analisador de espectro ou app de Wi-Fi para verificar canais ocupados pela vizinhança
• Identifique se o problema é específico de um usuário/dispositivo ou afeta todos no mesmo AP
• Verifique se há dispositivos de alta potência próximos (micro-ondas, telefone DECT 2.4 GHz, câmeras de segurança sem fio)

Nota de campo: Em ambientes corporativos com dezenas de APs, o técnico que não sabe ler um heatmap de cobertura vai passar horas no lugar errado. Essa é uma habilidade que vai além do A+, mas o A+ te dá o vocabulário para chegar lá.

3. Limited Connectivity — e o endereço 169.254.x.x

O que é: O Windows exibe “Conectado, sem acesso à internet” ou “Conectividade limitada” na bandeja do sistema. O dispositivo tem conexão física, mas não consegue alcançar recursos externos.

O que você vai encontrar no ipconfig: Um endereço no intervalo 169.254.0.1 a 169.254.254.254. Esse é um endereço APIPA — Automatic Private IP Addressing.

Por que o APIPA acontece: Quando um dispositivo não consegue obter um endereço IP de um servidor DHCP, o Windows atribui automaticamente um endereço do intervalo 169.254.x.x. Esse endereço é link-local: o dispositivo consegue se comunicar com outros dispositivos na mesma rede local que também tenham endereço APIPA, mas não consegue alcançar outros segmentos de rede, nem a internet.

Causas possíveis:

• Servidor DHCP fora do ar (desligado, reiniciando, esgotou o pool de endereços)
• VLAN configurada incorretamente (o dispositivo está no segmento errado e não tem DHCP relay)
• Problema de autenticação 802.1X antes de receber IP (o switch bloqueia o tráfego até a autenticação ser concluída)

Como diagnosticar:

• ipconfig /all — confirme se o endereço é 169.254.x.x
• ping <IP do servidor DHCP> — se não responder, o DHCP está inacessível
• Verifique se outros dispositivos na mesma rede têm o mesmo problema (indica DHCP com problema) ou se é isolado (indica problema na configuração do dispositivo ou da porta do switch)
• ipconfig /release seguido de ipconfig /renew — força uma nova tentativa de obter IP via DHCP

Detalhe importante para o exame: O A+ cobra a distinção entre “sem conectividade” (sem link light, sem IP) e “conectividade limitada” (tem link light, tem APIPA, DHCP falhou). São problemas diferentes com soluções diferentes.

4. Slow Network Speeds

O que é: A rede funciona, mas está visivelmente mais lenta que o esperado. Transferências de arquivo demoram, páginas carregam devagar, o servidor de arquivos parece lerdo.

Causas mais comuns:

• Congestionamento de banda: muitos dispositivos competindo pela mesma largura de banda
• Incompatibilidade de velocidade/duplex: um dispositivo negociando 100 Mbps half duplex quando deveria estar em 1 Gbps full duplex; as colisões geradas degradam o throughput real para bem abaixo do nominal
• Hardware degradado: switch com ASIC com defeito parcial, cabo categorizado abaixo do necessário (Cat 5 num link que deveria ser Cat 6), NIC com defeito
• Malware: alguns tipos de malware usam a interface de rede intensamente (DDoS, mineração, exfiltração de dados), consumindo largura de banda
• Driver desatualizado: NIC não usando recursos de offload corretamente

Como diagnosticar:

• Faça um speedtest da máquina afetada e compare com outra máquina na mesma rede
• Verifique a velocidade negociada da interface (ipconfig /all mostra “Link Speed” no Windows; logs do switch mostram a velocidade da porta)
• Capture o tráfego por alguns minutos — se a interface estiver saturada por um protocolo específico, isso aparece no Wireshark

5. High Latency

O que é: O tempo de resposta da rede está alto. ping retorna valores elevados (acima de 100ms para redes locais já é sinal de alerta; para WAN depende da distância). Aplicações web ficam lentas, mas não perdem conexão.

Relação com outros sintomas: Latência alta é causa de muitos outros problemas desta lista — jitter, má qualidade de VoIP, e até conectividade aparentemente intermitente (timeout de aplicações que não toleram demora).

Causas comuns:

• Congestionamento em um ponto da rota (gargalo de banda)
• Roteador ou switch sobrecarregado processando muitos pacotes
• Problema com o ISP ou com o roteamento externo
• Configuração incorreta de QoS priorizando tráfego menos crítico

Como diagnosticar:

• ping <destino> -t (Windows) para medir latência contínua
• tracert <destino> (Windows) ou traceroute (Linux) para identificar em qual salto a latência aumenta
• Se a latência aumenta no primeiro salto (seu gateway), o problema está na rede local
• Se aumenta em saltos externos, o problema está no ISP ou no caminho até o destino

6. Jitter

O que é: Jitter é variação na latência. Se um pacote leva 10ms, o próximo 25ms, o seguinte 8ms, o próximo 40ms — essa irregularidade é o jitter. Em transferências de arquivo, jitter alto é irrelevante (o TCP retransmite e ordena). Em comunicações em tempo real, jitter alto destrói a experiência.

Por que jitter afeta VoIP e vídeo mais que transferências de arquivo: Chamadas de voz e vídeo são isocrônicas — os pacotes precisam chegar em intervalos regulares para que o áudio e o vídeo sejam reconstruídos corretamente. Se um pacote chega fora de ordem ou com atraso variável, o buffer de jitter do dispositivo pode absorver pequenas variações, mas variações grandes resultam em áudio “robótico”, silêncios, ou cortes.

Causas comuns: rede congestionada, cabo com defeito em conexões cabeadas, interferência em conexões wireless.

Como mitigar: QoS (Quality of Service) — priorização de tráfego de tempo real sobre tráfego bulk. Em roteadores SOHO, há geralmente uma opção de QoS que permite dar prioridade a VoIP.

7. Poor VoIP Quality

O que é: Chamadas VoIP (Microsoft Teams, Zoom, telefonia IP) com áudio cortado, eco, atraso perceptível, ou travamentos de vídeo.

Relação com outros sintomas: Má qualidade de VoIP é quase sempre uma consequência — de latência alta, de jitter, de perda de pacotes, ou de banda insuficiente. Raramente é um problema isolado.

Diagnóstico estruturado:

1. Verifique a velocidade da conexão — VoIP de boa qualidade requer no mínimo 1 Mbps por chamada de voz, 3–5 Mbps por chamada de vídeo HD
2. Meça a latência para o servidor de VoIP — acima de 150ms de latência one-way, a qualidade percebida já cai
3. Meça o jitter — acima de 30ms de jitter, áudio fica irregular
4. Verifique se QoS está configurado para priorizar o tráfego de VoIP
5. Se o problema afeta apenas usuários wireless, suspeite de interferência ou sinal fraco

Ferramenta diagnóstica: O próprio cliente de VoIP geralmente tem um relatório de qualidade de chamada. Microsoft Teams, Zoom e Cisco Webex têm métricas de jitter, packetloss e latência acessíveis durante ou após a chamada.

8. External Interference

O que é: Degradação de sinal wireless causada por fontes externas de radiofrequência na mesma banda.

Fontes comuns de interferência:

• Micro-ondas: emitem RF na faixa de 2.4 GHz durante o funcionamento; dispositivos próximos a micro-ondas podem perder conectividade enquanto ele está em uso
• Telefones sem fio DECT (2.4 GHz): a versão mais antiga do padrão DECT usa 2.4 GHz e interfere com Wi-Fi
• Redes Wi-Fi vizinhas: em prédios comerciais com muitos inquilinos, sobreposição de canais é a causa mais comum de performance Wi-Fi ruim
• Câmeras de segurança sem fio: muitas câmeras baratas usam 2.4 GHz com sinal não padronizado
• Bluetooth: usa o espectro de 2.4 GHz com frequency hopping; em ambientes com muitos dispositivos Bluetooth ativos, pode causar degradação

Estratégia de mitigação: Migrar para 5 GHz (menos congestionado, alcance menor mas mais limpo) ou 6 GHz (Wi-Fi 6E, praticamente sem interferência de dispositivos legados). Em ambientes 2.4 GHz, usar canais 1, 6 ou 11 (os únicos que não se sobrepõem no espectro de 20 MHz).

9. Authentication Failures

O que é: O dispositivo tem conectividade física e recebe IP normalmente, mas não consegue acessar recursos protegidos. Mensagem de erro tipicamente: “Acesso negado”, “Credenciais inválidas”, “Impossível autenticar”.

Camadas onde a falha pode ocorrer:

Camada de rede (802.1X): Em redes corporativas com autenticação por porta, o switch pode bloquear todo o tráfego até que a autenticação seja concluída. Se o certificado do servidor RADIUS expirou, se o cliente não tem o certificado correto, ou se a conta do usuário está bloqueada no AD, a autenticação falha e o dispositivo fica sem acesso — mesmo com cabo e IP corretos.

Camada de aplicação: Senha errada, conta bloqueada por tentativas excessivas, sessão expirada que precisa de re-autenticação.

Problemas de sincronização de hora: Kerberos (protocolo de autenticação do Windows/AD) requer que o relógio do cliente e do servidor estejam sincronizados dentro de 5 minutos. Se o CMOS da máquina está descarregado e o relógio foi para 2001, a autenticação Kerberos vai falhar com um erro críptico que parece problema de credencial mas é problema de NTP.

Como diagnosticar:

• Verifique se o problema é de um usuário específico (credencial/conta) ou de um dispositivo específico (configuração/certificado)
• Verifique os logs do servidor de autenticação (Event Viewer no servidor, logs do RADIUS)
• Confirme a hora do dispositivo — se estiver errada, é o primeiro lugar a verificar

10. Intermittent Internet Connectivity

O que é: A conexão com a internet cai e volta de forma irregular. A rede local funciona normalmente — usuários conseguem acessar o servidor de arquivos, a impressora de rede, o servidor interno — mas o acesso externo falha intermitentemente.

A distinção crítica: Quando os usuários dizem “a internet caiu”, você precisa descobrir primeiro se é a internet que caiu ou se é só o acesso externo que está falhando. Se conseguem acessar recursos internos, a LAN está funcionando. O problema está no link WAN ou além.

Causas e onde investigar:

PARTE 3 — O FLUXO DO FÍSICO AO LÓGICO

Todos os dez sintomas acima têm uma lógica comum de diagnóstico. O modelo mais eficiente é trabalhar do físico para o lógico — começar na camada que você pode ver e tocar, e subir quando a camada inferior estiver confirmada como saudável.

CAMADA FÍSICA (Cabos, portas, link light)
│
│   Pergunta: Há link light? O cabo está íntegro?
│   Ferramentas: inspeção visual, testador de cabo
│   Sintomas associados: port flapping, sem conectividade total
│
▼
CAMADA DE ENDEREÇAMENTO (IP, DHCP, default gateway)
│
│   Pergunta: O dispositivo tem um IP válido?
│   Ferramentas: ipconfig, ping ao gateway
│   Sintomas associados: limited connectivity (APIPA), sem acesso externo
│
▼
CAMADA DE NOMES (DNS)
│
│   Pergunta: O nome resolve para IP corretamente?
│   Ferramentas: nslookup, ping por IP vs. por nome
│   Sintomas associados: acesso por IP funciona, por nome não
│
▼
CAMADA DE DESEMPENHO (Latência, jitter, banda)
│
│   Pergunta: A rede funciona mas está degradada?
│   Ferramentas: ping -t, tracert, speedtest, Wireshark
│   Sintomas associados: lentidão, jitter, má qualidade VoIP
│
▼
CAMADA DE ACESSO (Autenticação, firewall, permissão)
    Pergunta: O usuário tem permissão para acessar o recurso?
    Ferramentas: logs de autenticação, Event Viewer, packet capture
    Sintomas associados: authentication failures, acesso negado

A maioria dos problemas reais para na segunda camada. APIPA sozinho responde por uma parcela enorme dos chamados de “sem internet” que chegam ao helpdesk.

TABELA DE REFERÊNCIA RÁPIDA — SINTOMAS V15 OBJ 5.5

BYPASS CONSCIENTE

Este post cobre o Objetivo 5.5 do CompTIA A+ Core 1 (220-1201 V15): Given a scenario, troubleshoot network issues.

O documento oficial lista exatamente os dez sintomas abordados aqui. Você pode baixar os objetivos completos gratuitamente em comptia.org — procure por “220-1201 Exam Objectives” e baixe o PDF oficial.

O que foi coberto: todos os dez sintomas do objetivo: intermittent wireless connectivity, slow network speeds, limited connectivity, jitter, poor VoIP quality, port flapping, high latency, external interference, authentication failures, intermittent internet connectivity.

O que foi simplificado intencionalmente:

• Ferramentas de diagnóstico (Objective 2.8): ping, tracert, ipconfig, nslookup, netstat, Wireshark — foram mencionados aqui como contexto, mas o objetivo 2.8 (que já cobrimos no Post 10) é onde eles são tratados com profundidade.
• QoS avançado: A configuração detalhada de filas de prioridade em switches e roteadores gerenciados vai além do escopo do A+. O que o exame cobra é o conceito de que QoS existe e é a solução para jitter/VoIP em redes congestionadas.
• 802.1X e RADIUS em profundidade: O A+ cobre o conceito de autenticação por porta. A implementação completa com servidores RADIUS, NPS, e certificados é território de Network+ e Security+.

A PROVOCAÇÃO

Aqui está uma situação que acontece em ambientes corporativos com muito mais frequência do que parece:

Um usuário liga reclamando que “a internet não está funcionando”. Você verifica remotamente: o dispositivo tem um IP válido do DHCP (192.168.10.47), o ping para o gateway responde em 1ms, o nslookup google.com retorna o IP correto.

Mas o usuário não consegue abrir nenhum site no navegador.

O ping 8.8.8.8 responde normalmente. O ping google.com também responde normalmente. Mas o navegador continua dando erro.

O que você verifica a seguir?

A resposta está na documentação — mas exige que você entenda a diferença entre conectividade de rede e conectividade de aplicação, e saiba exatamente qual camada o navegador usa que ping não usa.

Se você encontrar a resposta sem minha ajuda, você está no caminho certo.

(Dica: começa com proxy.)

NO PRÓXIMO POST

O Post 20 fecha o Domínio 5.0 do Core 1 — e com ele, o exame 220-1201 está completo em termos de conteúdo nesta série.

A partir do Post 21, começamos o Core 2 (220-1202): sistemas operacionais, segurança, scripting e gestão de dispositivos. O primeiro parada é o Domínio 1.0 — Sistemas Operacionais: Windows, Linux, macOS, Chrome OS, e por que essa diversidade importa para quem trabalha em suporte corporativo.

Se você chegou até aqui pela sequência, parabéns — você percorreu o domínio de hardware e troubleshooting do zero ao Core 1. O Core 2 é onde o ambiente corporativo fica mais reconhecível: Active Directory, Group Policy, BitLocker, e o dia a dia real do suporte técnico.

Post 21 → Tipos de Sistemas Operacionais e suas Diferenças (Core 2, Obj 1.1)

CompTIA A+ é marca registrada da CompTIA, Inc. Este conteúdo educacional independente não é afiliado, endossado ou patrocinado pela CompTIA.