¿Por qué Test-NetConnection indica que se puede establecer la conexión, pero no puedo visitar el sitio?

Question

Necesito determinar si se puede acceder a un sitio en particular en un puerto en particular, dado que existen restricciones de firewall en la red.

Si no puedo acceder al sitio en un puerto en particular, eso significa que necesitaré modificar el firewall antes de continuar. De lo contrario, si puedo llegar al sitio, podré continuar con lo que pretendo hacer.

Quería saber si podía obtener un repositorio Githubusando la URL https del repositorio. Un ejemplo de URL https: https://github.com/git-for-windows/git.git. Esto se puede utilizar con cloney otras herramientas.

Para ver si podía acceder Githuby, por extensión, clonar el repositorio, ejecuté el siguiente comando:Test-NetConnection -ComputerName github.com -Port 443 |findstr "TcpTestSucceeded"

En el sistema, este comando devolvió lo siguiente, indicando que pude acceder github.comal puerto 443 (https).

TcpTestSucceeded : True

Sin embargo, luego abrí un navegador web, visité https://github.comy el navegador web indicó que no se podía establecer una conexión. https está a través del puerto 443 y el dominio es github.comigual al que puse en la prueba.

Mis preguntas son:

• ¿Por qué existe esta discrepancia entre las dos pruebas?
• ¿Cómo puedo probar con precisión CMDsi PowerShelltengo acceso a un dominio en particular a través de un puerto en particular?

Claramente, el Test-NetConnectioncomando no produjo resultados precisos, ya que el navegador web no pudo acceder github.com.

Answer 1

Claramente, el comando Test-NetConnection no produjo resultados precisos, ya que el navegador web no pudo acceder a github.com.

Esa no es una afirmación precisa.

De hecho, Test-NetConnection realizó una conexión TCP al puerto 443 del servidor de destino, verificando que el puerto TCP 443 en el servidor remoto esté en estado de escucha. Test-NetConnection no prueba qué aplicación/servicio se está ejecutando/escuchando en el puerto 443.

Básicamente, Test-NetConnection no puede decirle qué se está ejecutando/escuchando en la Capa 7, solo puede decirle que el puerto 443 está en estado de escucha.

Answer 2

Las dos declaraciones "se puede establecer la conexión" y "puedo continuar con lo que pretendo hacer" están lejos de ser equivalentes, y una simple prueba de conexión TCP Test-NetConnectionno prueba en absoluto lo mismo que una prueba git clone.

Poder abrir una conexión TCP a un puerto no implica acceder al servicio que escucha en ese puerto. Hay muchas etapas después de la conexión inicial que pueden fallar, como las negociaciones TLS, la autenticación, la autorización o los intercambios de protocolos a nivel de aplicación.

Además, las restricciones del firewall no son la única razón posible para que falle una conexión TCP, y los fallos de la conexión TCP no son el único efecto posible de una restricción del firewall. Entonces tus declaraciones:

Si no puedo acceder al sitio en un puerto en particular, eso significa que necesitaré modificar el firewall antes de continuar.

y

De lo contrario, si puedo llegar al sitio, podré continuar con lo que pretendo hacer.

ambos están equivocados. Esto significa que, en lugar de preguntarse por qué su Test-NetConnectionprueba no detectó el problema que luego provocó que fallara su acceso a GitHub, debe analizar cuál fue realmente ese problema y luego evaluar si detectar ese problema en particular con anticipación proporcionaría algún beneficio. Si la respuesta es sí, entonces puedes idear una prueba para hacer precisamente eso.

En la práctica, con frecuencia el curso de acción más eficaz es simplemente intentar la operación prevista sin pruebas previas y manejar los errores a medida que se produzcan. Verificar los problemas por adelantado solo tiene sentido si se pueden solucionar automáticamente o si intentar y fallar la operación real conlleva un costo o riesgo sustancial.

Específicamente, las operaciones de GitHub fallan con bastante gracia y con una indicación razonablemente clara de la causa del error, por lo que no veo ningún beneficio directo en probar primero la conexión en lugar de simplemente intentar la operación prevista directamente.