Por que o Test-NetConnection indica que a conexão pode ser feita, mas não consigo visitar o site?

Question

Preciso determinar se um site específico está acessível em uma porta específica, visto que existem restrições de firewall na rede.

Se eu não conseguir acessar o site em uma porta específica, isso significa que precisarei modificar o firewall antes de continuar. Caso contrário, se eu conseguir acessar o site, poderei prosseguir com o que pretendo fazer.

Eu queria saber se poderia buscar um repositório Githubusando o URL https do repositório. Um exemplo de URL https: https://github.com/git-for-windows/git.git. Isso pode ser usado com cloneoutras ferramentas.

Para ver se conseguia acessar Githube, por extensão, clonar o repositório, executei o seguinte comando:Test-NetConnection -ComputerName github.com -Port 443 |findstr "TcpTestSucceeded"

No sistema, este comando retornou o seguinte, indicando que consegui acessar github.coma porta 443 (https).

TcpTestSucceeded : True

No entanto, abri um navegador da web e visitei o https://github.com, e o navegador da web indicou que não foi possível estabelecer uma conexão. https passa pela porta 443 e o domínio é github.comigual ao que coloquei no teste.

Minhas perguntas são:

• Por que existe essa discrepância entre os dois testes?
• Como posso testar com precisão CMDou PowerShellse tenho acesso a um domínio específico em uma porta específica?

Claramente, o Test-NetConnectioncomando não produziu resultados precisos, pois o navegador da web não conseguiu acessar o arquivo github.com.

Answer 1

Claramente, o comando Test-NetConnection não produziu resultados precisos, pois o navegador da web não conseguiu acessar github.com.

Essa não é uma afirmação precisa.

De fato, o Test-NetConnection fez uma conexão TCP com a porta 443 do servidor de destino, verificando se a porta TCP 443 no servidor remoto está no estado de escuta. Test-NetConnection não testa qual aplicativo/serviço está sendo executado/escutando na porta 443.

Essencialmente, Test-NetConnection não pode dizer o que está sendo executado/escutando na Camada 7, apenas pode dizer que a porta 443 está no estado de escuta.

Answer 2

As duas afirmações "a conexão pode ser feita" e "eu sou capaz de prosseguir com o que pretendo fazer" estão longe de ser equivalentes, e um simples teste de conexão TCP como Test-NetConnectionnão testa a mesma coisa que um arquivo git clone.

Ser capaz de abrir uma conexão TCP com uma porta não implica acesso ao serviço que escuta naquela porta. Existem muitos estágios após a conexão inicial que podem falhar, como negociações TLS, autenticação, autorização ou trocas de protocolo em nível de aplicativo.

Além disso, as restrições de firewall não são o único motivo possível para a falha de uma conexão TCP, e as falhas da conexão TCP não são o único efeito possível de uma restrição de firewall. Então suas declarações:

Se eu não conseguir acessar o site em uma porta específica, isso significa que precisarei modificar o firewall antes de continuar.

e

Caso contrário, se eu conseguir acessar o site, poderei prosseguir com o que pretendo fazer.

ambos estão errados. Isso significa que, em vez de se perguntar por que seu Test-NetConnectionteste não detectou o problema que mais tarde causou a falha no acesso ao GitHub, você deve analisar qual era realmente esse problema e, em seguida, avaliar se a detecção antecipada desse problema específico traria algum benefício. Se a resposta for sim, você pode criar um teste para fazer exatamente isso.

Na prática, frequentemente o curso de ação mais eficiente é apenas tentar a operação pretendida sem quaisquer testes anteriores e tratar quaisquer erros à medida que ocorrem. A verificação antecipada de problemas só faz sentido se eles puderem ser corrigidos automaticamente ou se tentar e falhar na operação real acarretar um custo ou risco substancial.

Especificamente, as operações do GitHub falham normalmente e com uma indicação razoavelmente clara da causa da falha, portanto, não vejo nenhum benefício direto em testar a conexão primeiro, em vez de apenas tentar diretamente a operação pretendida.