Antes dos dias do cmdlet Test-NetConnection do PowerShell, tínhamos muitas ferramentas de linha de comando diferentes das quais podíamos escolher para solucionar vários problemas de conectividade de rede.
Tínhamos ping para testar eco e respostas ICMP; tracert para ver onde nossos pacotes poderiam estar sendo descartados; nslookup para realizar consultas DNS contra nossos servidores DNS; telnet para verificar portas TCP abertas, e vários outros utilitários. Havia uma utilidade para tudo.
Com a introdução do PowerShell v4 no Windows 8.1 e no Windows Server 2012 R2, essa abordagem de uma única utilidade para uma única tarefa para solucionar problemas de conectividade tornou-se obsoleta.
Permita-me apresentar-lhe o novo e poderoso cmdlet Test-NetConnection. Pense no Test-NetConnection do PowerShell como ping, tracert, nslookup, telnet e alguns outros utilitários envoltos em uma única suíte de bondade de solução de problemas.
Solucionando problemas com Test-NetConnection
Vamos ver o que podemos fazer com o cmdlet test-netconnection do Powershell e como podemos usá-lo quando estamos na infeliz posição de solucionar um problema de conectividade de rede.
Para demonstrar isso, vou usar o PowerShell Test-NetConnection para solucionar um problema comum do mundo real: “Não consigo acessar o site XYZ!”
O que a maioria dos usuários não sabe é que conseguir renderizar um site em um navegador é, por si só, uma proeza incrível, considerando o número de peças em movimento que precisam funcionar juntas para que isso aconteça. No mínimo, o processo envolve:
- Ter uma conexão com a internet.
- Ter uma rota para o seu servidor DNS.
- Entrar em contato com o servidor DNS para resolver a URL.
- Ter uma rota para o endereço IP ao qual a URL é resolvida.
- Ter a porta TCP 80 aberta.
- e assim por diante.
Confirme Sua Conexão com a Internet
Para começar a solucionar problemas, você primeiro precisa confirmar se tem uma conexão com a internet. Você pode fazer isso simplesmente executando o PowerShell Test-NetConnection sem nenhum parâmetro. No entanto, se você quiser obter mais informações, sugiro usar o parâmetro InformationLevel com o argumento Detailed.
Este comando simples verifica sua conectividade local e com a internet e confirma que seu cliente DNS pode resolver nomes direcionados ao seu servidor DNS, tudo de uma vez. Considere-o como uma verificação geral de saúde para sua conexão de rede. Este comando verifica três dos cinco processos necessários para renderizar um site de uma só vez!
Use Test-NetConnection para Testar Sua Conexão com o Host do Site
Vamos agora direcionar nossa solução de problemas para o host do site em questão. Vamos usar o google.com como exemplo. Você também pode usar um computador remoto.
Podemos usar o Test-NetConnection com o parâmetro ComputerName para garantir simultaneamente que o host do site possa ser resolvido no DNS, que existe uma rota TCP disponível para chegar ao endereço IP para o qual o nome se resolve e que é possível fazer ping nele.
Mesmo que este passo tecnicamente verifique se temos uma rota para o servidor web do google.com, quero encontrar informações mais detalhadas sobre quais roteadores meus pacotes estão atravessando para chegar ao servidor web do google.com. Para fazer isso, vou usar o parâmetro TraceRoute para obter uma lista.
Garanta que sua porta TCP esteja aberta
Nosso teste final é garantir que a porta TCP na qual esperamos que o servidor web esteja em execução esteja aberta. Neste caso, como estamos apenas especificando o google.com, vou assumir que é a porta TCP 80. Para fazer isso, vamos simplesmente adicionar outro parâmetro ao Test-NetConnection. Como o Test-NetConnection entende a porta TCP padrão para alguns serviços diferentes, nem precisamos saber o número da porta. Posso simplesmente passar HTTP para o parâmetro CommonTCPPort e ele fará o trabalho por mim.
No entanto, se o site estiver sendo executado em uma porta diferente, como 8080, você pode especificar uma porta TCP diretamente usando o parâmetro Port.
Testamos agora cada um dos requisitos de conectividade delineados no início deste artigo. Se ainda não conseguirmos renderizar o site neste momento, confirmamos que o problema não está com nosso cliente, e podemos encaminhar o problema para o Google ou talvez para um servidor DNS secundário.