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árias outras utilidades. 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 todo-poderoso cmdlet Test-NetConnection. Pense no Test-NetConnection do PowerShell como ping, tracert, nslookup, telnet e algumas outras utilidades reunidas em um único conjunto de ferramentas de solução de problemas.
Solução de problemas com Test-NetConnection
Vamos ver o que podemos fazer com o cmdlet Powershell test-netconnection e ver como podemos usá-lo quando estamos na posição infeliz 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 renderizar com sucesso um site em um navegador é, em si, uma proeza incrível, considerando o número de peças móveis que precisam funcionar em conjunto para que isso aconteça. No mínimo, o processo envolve:
- Ter uma conexão com a internet.
- Ter uma rota para seu servidor DNS.
- Entrar em contato com o servidor DNS para resolver a URL.
- Ter uma rota para o endereço IP para o qual a URL é resolvida.
- Ter a porta TCP 80 aberta.
- Etc., etc.
Confirme sua conexão com a internet
Para começar a solucionar, 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 quiser obter mais informações, sugiro usar o parâmetro `InformationLevel` com o argumento `Detailed`.
Este comando simples verifica sua conectividade local e conectividade com a internet, confirma que seu cliente DNS pode resolver nomes direcionados ao seu servidor DNS, tudo de uma vez. Considere isso 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 vez só!
Use o Test-NetConnection para Testar Sua Conexão com o Host do Site
Precisaremos agora direcionar nossa solução de problemas para o provedor de hospedagem do site em questão. Vamos usar o google.com como exemplo. Você também poderia 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 ele possa ser pingado.
Embora esse passo tecnicamente verifique se temos uma rota para o servidor da web google.com, quero encontrar informações mais detalhadas sobre quais roteadores meus pacotes estão passando para chegar ao servidor da web 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 google.com, vou assumir que é a porta TCP 80. Para fazer isso, simplesmente adicionaremos outro parâmetro ao Test-NetConnection. Como o Test-NetConnection entende a porta TCP padrão para alguns serviços diferentes, nem mesmo precisamos saber o número da porta. Posso simplesmente passar HTTP para o parâmetro CommonTCPPort e ele fará o trabalho para 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 em vez disso.
Nós 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 um servidor DNS downstream.