Antes de los días del cmdlet Test-NetConnection de PowerShell, teníamos muchas herramientas de línea de comandos diferentes entre las que podíamos elegir para solucionar varios problemas de conectividad de red.
Teníamos ping para probar ecos y respuestas ICMP; tracert para ver dónde podrían estar cayendo nuestros paquetes; nslookup para realizar consultas DNS contra nuestros servidores DNS; telnet para verificar los puertos TCP abiertos, y varias otras utilidades. Había una utilidad para todo.
Con la introducción de PowerShell v4 en Windows 8.1 y Windows Server 2012 R2, este enfoque de una sola utilidad para una sola tarea para solucionar problemas de conectividad se ha vuelto obsoleto.
Permítame presentarle el nuevo y poderoso cmdlet Test-NetConnection. Piense en el Test-NetConnection de PowerShell como ping, tracert, nslookup, telnet y algunas otras utilidades envueltas en un solo conjunto de bondades para solucionar problemas.
Solución de problemas con Test-NetConnection
Veamos qué podemos hacer con el cmdlet test-netconnection de PowerShell y veamos cómo podemos usarlo cuando estamos en la desafortunada posición de solucionar un problema de conectividad de red.
Para demostrar esto, voy a usar PowerShell `Test-NetConnection` para solucionar un problema común del mundo real: ¡”No puedo acceder al sitio web XYZ!”
Lo que la mayoría de los usuarios no saben es que renderizar exitosamente un sitio web en un navegador es, en sí mismo, un logro asombroso considerando la cantidad de piezas en movimiento que deben funcionar juntas para que eso suceda. Como mínimo, el proceso implica:
- Tener una conexión a internet.
- Tener una ruta hacia su servidor DNS.
- Contactar al servidor DNS para resolver la URL.
- Tener una ruta hacia la dirección IP a la que resuelve la URL.
- Tener el puerto TCP 80 abierto.
- Y así sucesivamente, y así sucesivamente.
Confirma tu conexión a Internet
Para comenzar a solucionar problemas, primero debes confirmar que tienes una conexión a internet. Puedes hacer esto simplemente ejecutando PowerShell `Test-NetConnection` sin ningún parámetro. Sin embargo, si deseas obtener más información, te sugiero usar el parámetro `InformationLevel` con el argumento `Detailed`.
Este comando simple verifica tu conectividad local y conectividad a internet, y confirma que tu cliente DNS puede resolver nombres dirigidos a tu servidor DNS, ¡todo de una vez! Considera que es una verificación general de la salud de tu conexión de red. ¡Este comando verifica tres de los cinco procesos necesarios para renderizar un sitio web de una vez!
Usa Test-NetConnection para Probar tu Conexión con el Host del Sitio Web
Necesitaremos dirigir nuestra solución de problemas al servidor web en cuestión. Utilicemos google.com como ejemplo. También podrías utilizar un ordenador remoto.
Podemos utilizar Test-NetConnection con el parámetro ComputerName para asegurarnos simultáneamente de que el servidor web pueda ser resuelto en DNS, que haya una ruta TCP disponible para llegar a la dirección IP a la que se resuelve el nombre, y que se pueda hacer ping.
Aunque este paso técnicamente verifica que tenemos una ruta al servidor web de google.com, quiero encontrar información más detallada sobre qué routers están pasando mis paquetes para llegar al servidor web de google.com. Para hacer eso, usaré el parámetro TraceRoute para obtener una lista.
Asegúrate de que tu puerto TCP esté abierto
Nuestra prueba final es asegurarnos de que el puerto TCP en el que esperamos que el servidor web esté funcionando esté abierto. En este caso, como solo estamos especificando google.com, voy a asumir que es el puerto TCP 80. Para hacerlo, simplemente agregaremos otro parámetro a Test-NetConnection. Debido a que Test-NetConnection entiende el puerto TCP estándar para varios servicios diferentes, ni siquiera necesitamos conocer el número de puerto. Puedo simplemente pasar HTTP al parámetro CommonTCPPort y hará el trabajo por mí.
Sin embargo, si el sitio web podría estar funcionando bajo un puerto diferente, como 8080, puedes especificar un puerto TCP directamente usando el parámetro Port en su lugar.
Hemos probado ahora cada uno de los requisitos de conectividad mencionados al principio de este artículo. Si aún no podemos renderizar el sitio web en este momento, hemos confirmado que el problema no reside en nuestro cliente, y podemos pasar el problema a Google o tal vez a un servidor DNS aguas abajo.