Troubleshooting de rede: um fluxo prático de DNS, rota, portas e TLS

Um método reproduzível para diagnosticar problemas de conectividade separando resolução DNS, caminho de rede, portas, HTTP e TLS.

Problemas de rede ficam mais difíceis quando vários testes são executados sem uma ordem clara. Um domínio pode resolver corretamente e ainda assim o serviço estar indisponível; uma porta pode aceitar conexão enquanto o TLS falha; um traceroute pode mostrar asteriscos sem que exista perda real para a aplicação.

Um fluxo consistente reduz esse ruído. A ideia é validar cada camada separadamente e só avançar quando a anterior fizer sentido.

1. Comece pelo nome: DNS

Antes de testar portas ou aplicação, confirme para onde o nome está apontando.

No Linux:

dig example.com A
dig example.com AAAA
dig example.com NS

No Windows:

Resolve-DnsName example.com

Procure principalmente por:

• endereço inesperado;
• diferença entre IPv4 e IPv6;
• CNAME apontando para serviço antigo;
• servidores autoritativos incorretos;
• respostas diferentes entre resolvers.

Para uma visão consolidada, o DNS Lookup do Bit Happens permite consultar diretamente os principais tipos de registro.

Se o problema envolve e-mail, vale validar também MX, SPF, DMARC e DNSSEC no Domain Health.

2. Confirme o IP e o contexto da rede

Depois de descobrir o endereço de destino, confirme se ele pertence à infraestrutura esperada.

Algumas verificações úteis:

dig +short example.com
whois 203.0.113.10

WHOIS tradicional ainda aparece em muitos fluxos, mas RDAP é hoje uma alternativa estruturada para consultar registro, organização e blocos IP.

O RDAP / WHOIS e o IP / ASN Context ajudam a separar rapidamente um endereço próprio de um CDN, provedor cloud ou terceiro.

3. Teste conectividade TCP antes da aplicação

Ping não confirma se um serviço está funcionando. Muitos ambientes bloqueiam ICMP e continuam atendendo HTTP, SSH ou outros serviços normalmente.

Teste a porta que realmente importa.

Linux:

nc -vz example.com 443

Windows:

Test-NetConnection example.com -Port 443

Interprete o resultado com cuidado:

• conectou: existe caminho TCP até aquela porta;
• connection refused: o host respondeu, mas nada está aceitando conexão naquela porta;
• timeout: pode haver firewall, ACL, rota incompleta ou serviço silenciosamente descartando pacotes.

Para uma visão externa, o Port Check testa conectividade TCP a partir da infraestrutura do portal.

Isso é útil porque um serviço pode funcionar de dentro da empresa e estar bloqueado para a Internet — ou o inverso.

4. Use traceroute para entender o caminho, não como prova isolada

Traceroute ajuda a localizar mudanças de rota e pontos onde a latência começa a crescer, mas precisa ser interpretado corretamente.

Linux:

traceroute example.com

Windows:

tracert example.com

Asteriscos em um hop intermediário não significam necessariamente perda. Roteadores podem encaminhar tráfego normalmente e limitar ou ignorar as respostas usadas pelo traceroute.

O que merece atenção é:

• mudança abrupta e persistente de latência;
• rota indo para uma região ou operadora inesperada;
• perda que começa em um hop e continua até o destino;
• diferença relevante entre caminhos IPv4 e IPv6.

Para facilitar a leitura, é possível colar a saída no Traceroute ou usar o Traceroute Visual para visualizar os hops públicos.

5. Se a porta 443 responde, valide HTTP e TLS separadamente

Uma conexão TCP bem-sucedida não significa que o HTTPS esteja saudável.

Primeiro veja o comportamento HTTP:

curl -IL https://example.com

Para detalhes:

curl -Iv https://example.com

Verifique:

• status HTTP;
• sequência de redirects;
• hostname final;
• headers;
• erros de certificado;
• versão TLS negociada.

Depois valide o certificado diretamente:

openssl s_client -connect example.com:443 -servername example.com

O parâmetro -servername envia SNI. Sem ele, servidores com múltiplos sites podem apresentar outro certificado e produzir um falso diagnóstico.

O TLS Inspector reúne validação HTTPS, SNI e metadados públicos do certificado.

6. Diferencie problema de DNS, rede e aplicação

Uma matriz simples evita gastar tempo na camada errada:

Isso não substitui investigação, mas ajuda a escolher o próximo teste.

7. Compare a visão interna com a visão externa

Esse é um dos testes mais úteis em ambientes corporativos.

Faça o mesmo diagnóstico de dois pontos:

1. de dentro da rede;
2. de uma origem externa.

Diferenças podem revelar:

• split DNS;
• NAT;
• regras de firewall;
• CDN ou proxy reverso;
• publicação incorreta;
• rota assimétrica;
• ACL baseada em origem.

O Network Diagnostic foi criado justamente para reunir DNS, RDAP, ASN, HTTP/TLS, portas, Nmap controlado e comandos de traceroute em um único fluxo.

Um fluxo curto para incidentes

Quando preciso reduzir rapidamente o espaço de busca, a sequência é:

1. resolver o nome
2. confirmar o IP esperado
3. testar a porta do serviço
4. observar a rota quando necessário
5. validar HTTP
6. validar TLS
7. comparar dentro × fora
8. só então aprofundar no serviço ou aplicação

A principal vantagem não é executar mais comandos. É executar o próximo teste certo com base no resultado anterior.

Esse método torna o troubleshooting mais previsível e produz evidências melhores para envolver redes, segurança, infraestrutura ou aplicação quando o incidente atravessa equipes.