Antes de que existiera el Test-NetConnection de PowerShell, existía una gran cantidad herramientas que teníamos a nuestra disposición para resolver problemas de la conexión a la red. Existía ping para probar los ecos de envío y de respuesta del Protocolo de Mensajes de Control de Internet (ICMP por sus siglas en ingles); el tracert para seguir la trayectoria de los paquetes; el nslookup para consultar los servidores de Sistema de Nombres de Dominio (DNS en ingles); el telnet para verificar si hay puertos de Protocolo de control de transmisión (TCP en ingles) abiertos; y una gran cantidad de utilidades diversas. Había una utilidad para todo.
Al introducir el PowerShell v4 en Windows 8.1 y el servidor de Windows R2 del 2012, la estrategia para resolver problemas de conectividad de solamente tener una herramienta para resolver un solo problema se ha convertido completamente obsoleta. Permítame presentarle el novedoso, todo poderoso comándulo Test-NetConnection de PowerShell. Imagine que Test-NetConnection de PowerShell es ping, tracert, nslookup, telnet y otras herramientas envueltas en tan solo una.
Cómo resolver problemas de la conexión a la red con el Test-NetConnection
Veamos qué es lo que podemos hacer con el comándulo Test-NetConnection y cómo lo podemos usar cuando estamos en la situación desafortunada de tener que resolver algún problema de la conexión a la red. Para demostrarlo, usare el Test-NetConnection de PowerShell y resolveré un problema común: “No puedo acceder el sitio XYZ!”
Varios usuarios no saben que, el interpretar un sitio de manera exitosa en un buscador es un gran logro, ya que muchas piezas que tienen que funcionar simultáneamente. Al nivel mínimo, el proceso implica lo siguiente:
- Tener conexión al internet.
- Tener una ruta al servidor Sistema de Nombres de Dominio (DNS).
- Contactar el servidor DNS para resolver el Localizador Uniforme de Recursos, LUR (o URL en ingles).
- Tener una ruta en la que el URL pueda llegar a la dirección IP.
- Tener el puerto TCP 80 abierto.
- Etcétera, etcétera …
Primer paso: confirme su conexión al internet
Para empezar a resolver el problema, primero necesitara cerciorarse de que tenga conexión al internet. Puede hacerlo fácilmente ejecutando el Test-NetConnection de PowerShell sin ningún parámetro. Sin embargo, si desea obtener más información, le recomiendo que use el parámetro de InformationLevel con el argumento Detailed.
Test-NetConnection -InformationLevel Detailed
En un solo proceso, este simple comando verifica su conectividad local y al internet y confirma que su cliente DNS pueda resolver los nombres dirigidos a su servidor DNS. Considérelo como un chequeo de salud general de la conexión de red. Este comando realiza tres de los cinco procesos necesarios para interpretar un sitio.
Segundo paso: Verifique la conexión con el anfitrión web
Nuestro siguiente será resolver el problema con el anfitrión web involucrado. Usemos google.com como un ejemplo. Podemos usar Test-NetConnection con el parámetro ComputerName para asegurarnos de que el anfitrión web pueda ser resuelto en DNS, y que exista una trayectoria TCP para adquirir la dirección IP en la que el nombre se resuelva, y de que pueda ser alertado.
Test-NetConnection -ComputerName google.com
Aunque este paso técnicamente verifique que tenemos una ruta al servidor web google.com, quiero tener información más detallada sobre que routers están utilizando mis paquetes para llegar al servidor web de google.com. Para hacer eso, usare el parámetro TraceRoute para obtener una lista.
Test-NetConnection -ComputerName google.com -TraceRoute
Tercer paso: Asegúrese de que su puerto TCP esté abierto
El último paso es asegurarnos de que el puerto TCP que usa el sitio para funcionar este abierto. En este caso, como estamos especificando google.com, asumiré de que es el puerto TCP 80. Para lograr esto, simplemente añadiremos un parámetro más a Test-NetConnection. Ya que Test-NetConnection es capaz de entender puertos estándares TCP de unos cuantos servicios, no tenemos que preocuparnos del número exacto. Simplemente le pasamos el HTTP al parámetro CommonTCPPort y hará el trabajo por nosotros.
Test-NetConnection -ComputerName google.com -CommonTCPPortHTTP
Sin embargo, si el sitio está funcionando con un puerto diferente como el 8080, puede especificar el puerto TCP directamente usando el parámetro Port.
Test-NetConnection -ComputerName google.com -Port80
Hemos realizado pruebas a cada requisito de conectividad mencionado al inicio del artículo. Si todavía no podemos interpretar el sitio, hemos confirmado que el problema no es del cliente, y podemos darle el problema a Google o quizás al servidor downstream DNS.