Um teste que passa reduz as hipóteses, mas é preciso saber exatamente o que ele provou e o que continua em aberto. Concluir mais do que o teste mostrou é uma das origens mais comuns de diagnósticos errados.
O que cada teste bem-sucedido prova
- O ipconfig mostra a configuração esperada: a interface tem os parâmetros corretos. A comunicação ainda precisa ser testada.
- O ping no gateway responde: houve comunicação ICMP de ida e volta até o gateway, o que confirma o caminho na rede local até o gateway. O acesso externo ainda não foi testado.
- O ping em um endereço externo responde: houve comunicação ICMP até aquele destino. As portas e os serviços ainda não foram testados.
- O nslookup devolve o endereço esperado: o servidor DNS consultado respondeu corretamente. O arquivo hosts ainda pode desviar o nome, e a conexão ainda não foi testada.
- O netstat mostra o estado LISTENING: existe um serviço à espera de conexões naquele endereço e naquela porta. O acesso a partir de outros computadores ainda não foi testado.
- O Test-NetConnection passa no próprio servidor: a conexão TCP abriu no teste local. O firewall do servidor e a rede ainda não foram testados.
- O Test-NetConnection passa a partir de outro computador: a conexão TCP abriu a partir daquela origem. A aplicação ainda não foi testada.
- O teste externo no endereço público passa: a conexão atravessou o caminho até a porta publicada. A autenticação e o protocolo da aplicação ainda não foram testados.
- O curl recebe uma resposta HTTP: o nome, a conexão e a negociação de segurança funcionaram. O conteúdo da resposta ainda precisa ser analisado.
O que um teste que falha permite concluir
Um teste que falha também precisa ser lido com cuidado:
- um ping sem resposta não prova que o equipamento está desligado, porque o ICMP pode estar bloqueado;
- um teste de porta que falha na hora indica recusa, e a investigação segue para o serviço;
- um teste de porta que demora até falhar indica tempo esgotado, e a investigação segue para o caminho e para os filtros;
- um nslookup sem resposta indica um problema no servidor DNS consultado, e não na conexão com o destino.
No suporte
Convém registrar no atendimento o que foi observado e quais hipóteses ficaram menos prováveis, sem concluir mais do que o teste mostrou. O registro evita que o próximo técnico repita os mesmos testes ou parta de uma conclusão errada.
Para guardar
- Um teste que passa reduz as hipóteses, mas não prova mais do que verificou.
- Cada teste deixa hipóteses em aberto, que precisam de outros testes.
- Um teste que falha também tem um alcance limitado.
- Registrar as evidências evita conclusões precipitadas.
O nslookup devolveu o endereço esperado. Isso prova que a aplicação vai conectar?
Não. O resultado prova apenas que o servidor DNS consultado respondeu corretamente. A conexão TCP e a aplicação ainda precisam ser testadas, e o arquivo hosts ainda pode desviar o nome.
O Test-NetConnection na porta 3306 passa a partir do caixa 01, mas o sistema continua sem acessar o banco de dados. Quais hipóteses continuam em aberto?
As hipóteses da camada de Aplicação: o usuário e a senha do banco de dados, a permissão de acesso a partir do caixa 01, o nome do banco configurado no sistema e a compatibilidade de versão. A rede e a porta já foram confirmadas.