Test-NetConnection: probar puertos y rutas en PowerShell

Durante años, comprobar si un servidor respondía y si un puerto estaba abierto obligaba a combinar tres herramientas: ping, tracert y un cliente telnet que ni siquiera venía instalado. Test-NetConnection reúne las tres en un único cmdlet de PowerShell: comprueba la conectividad, prueba puertos TCP concretos, traza la ruta hasta el destino y muestra información de diagnóstico de red, todo con una salida en forma de objeto que puedes usar en tus scripts. En esta guía verás cómo usarlo, qué significa cada resultado, cómo aplicarlo a varios equipos y puertos a la vez y cuáles son sus límites.

Qué es y dónde está disponible

Test-NetConnection pertenece al módulo NetTCPIP de Windows, que forma parte del sistema desde Windows 8.1 y Windows Server 2012 R2. Funciona tanto en Windows PowerShell 5.1 como en PowerShell 7 ejecutado en Windows, sin instalar nada. Tiene un alias corto, tnc, que puedes usar en la consola (en scripts es mejor escribir el nombre completo). No existe en PowerShell para Linux o macOS.

Estos son los parámetros que ofrece (los puedes ver con (Get-Command Test-NetConnection).Parameters.Keys):

-ComputerName: el nombre o la dirección IP del destino.
-Port: el puerto TCP que quieres probar.
-CommonTCPPort: un nombre de puerto común (HTTP, RDP, SMB o WINRM) en lugar del número.
-InformationLevel: Quiet (devuelve solo verdadero o falso) o Detailed (más información).
-TraceRoute y -Hops: traza la ruta hasta el destino y limita el número de saltos.
-DiagnoseRouting: muestra información sobre cómo enruta el sistema el tráfico hacia el destino.
-ConstrainSourceAddress y -ConstrainInterface: fuerzan la dirección de origen o la interfaz de red usadas en la prueba.

Uso básico: ¿responde el equipo?

Test-NetConnection 192.168.1.10
Test-NetConnection www.microsoft.com

Sin más parámetros, el cmdlet resuelve el nombre (si lo has indicado), envía una solicitud ICMP (el «ping») y muestra un resumen:

ComputerName           : www.microsoft.com
RemoteAddress          : 23.x.x.x
InterfaceAlias         : Ethernet
SourceAddress          : 192.168.1.25
PingSucceeded          : True
PingReplyDetails (RTT) : 18 ms

El campo PingSucceeded indica si el destino respondió, y PingReplyDetails (RTT) es el tiempo de ida y vuelta. Fíjate también en InterfaceAlias y SourceAddress: te dicen por qué tarjeta de red y con qué dirección sale el tráfico, algo muy útil en equipos con varias redes o con VPN.

Probar un puerto TCP: el sustituto de Telnet

Esta es la función estrella: comprobar si un servicio escucha en un puerto sin instalar el cliente Telnet.

Test-NetConnection servidor01 -Port 443
Test-NetConnection servidor01 -Port 3389
Test-NetConnection servidor01 -CommonTCPPort RDP

# Solo el resultado, ideal para scripts
Test-NetConnection servidor01 -Port 445 -InformationLevel Quiet

La salida añade dos campos: RemotePort y, sobre todo, TcpTestSucceeded, que es True si se estableció la conexión TCP. Con -InformationLevel Quiet el cmdlet devuelve únicamente True o False, lo que permite usarlo directamente en una condición:

if (Test-NetConnection servidor01 -Port 5985 -InformationLevel Quiet) {
    'WinRM responde: puedo administrar el equipo de forma remota'
} else {
    'WinRM no responde'
}

Los nombres de puerto comunes

-CommonTCPPort HTTP equivale al puerto 80.
-CommonTCPPort RDP, al 3389 (Escritorio remoto).
-CommonTCPPort SMB, al 445 (archivos compartidos).
-CommonTCPPort WINRM, al 5985 (administración remota con PowerShell).

Para cualquier otro servicio, usa el número con -Port: 22 (SSH), 25 (SMTP), 53 (DNS sobre TCP), 389 (LDAP), 443 (HTTPS), 1433 (SQL Server), 3306 (MySQL), etc.

Trazar la ruta (el sustituto de tracert)

Test-NetConnection 8.8.8.8 -TraceRoute
Test-NetConnection www.microsoft.com -TraceRoute -Hops 15

Además del resumen, aparece una lista TraceRoute con las direcciones de cada salto que atraviesa el tráfico. Si un salto aparece como 0.0.0.0 o «TimedOut», normalmente es un router que no responde a las solicitudes de traza pero reenvía el tráfico con normalidad; lo importante es dónde se corta definitivamente la ruta y si el destino final responde.

Cómo interpretar los resultados

PingSucceeded: True y TcpTestSucceeded: True: todo bien. El equipo es alcanzable y el servicio escucha.
PingSucceeded: False pero TcpTestSucceeded: True: el servidor funciona, pero bloquea ICMP (algo muy común). No lo consideres un fallo: el ping no es una prueba fiable de que un servicio esté caído.
TcpTestSucceeded: False con ping correcto: el equipo está, pero el puerto está cerrado, filtrado por un cortafuegos o el servicio no está en ejecución. Revisa el servicio, el cortafuegos de Windows del servidor y los cortafuegos de red.
«WARNING: Name resolution of … failed»: el nombre no se resuelve. Comprueba el DNS con Resolve-DnsName o prueba con la dirección IP para aislar el problema.
«WARNING: TCP connect to (IP : puerto) failed»: la conexión TCP no se estableció; es el mensaje habitual cuando el puerto no está accesible.
Ni ping ni puerto: comprueba la red, el enrutamiento (-TraceRoute), que el equipo está encendido y que estás en la VLAN correcta.

Probar varios puertos o varios equipos

Para comprobar una lista, combina el cmdlet con un bucle. Por ejemplo, los puertos que necesita un controlador de dominio:

$destino = 'dc01.empresa.local'
53, 88, 135, 389, 445, 464, 3268 | ForEach-Object {
    $r = Test-NetConnection $destino -Port $_ -WarningAction SilentlyContinue
    [pscustomobject]@{ Equipo = $destino; Puerto = $_; Abierto = $r.TcpTestSucceeded }
} | Format-Table -AutoSize

Y la misma prueba contra varios servidores, para tener un informe de estado de un servicio:

'srv01','srv02','srv03' | ForEach-Object {
    [pscustomobject]@{
        Servidor = $_
        RDP      = Test-NetConnection $_ -Port 3389 -InformationLevel Quiet -WarningAction SilentlyContinue
        WinRM    = Test-NetConnection $_ -Port 5985 -InformationLevel Quiet -WarningAction SilentlyContinue
    }
} | Format-Table -AutoSize

Si trabajas con PowerShell 7, puedes acelerar la comprobación de listas largas ejecutando las pruebas en paralelo con ForEach-Object -Parallel. Para repasar bucles y filtros, tienes la guía de bucles en PowerShell. Puedes guardar los resultados en un archivo con Export-Csv, como explicamos en los 10 comandos de PowerShell imprescindibles.

Separar los fallos de nombre de los fallos de red

Cuando una prueba falla, lo primero es saber si el problema está en resolver el nombre o en llegar al destino. Hazlo en dos pasos: primero consulta el DNS y, después, prueba la conexión directamente por dirección IP:

Resolve-DnsName servidor01.empresa.local          # ¿qué IP devuelve el DNS?
Test-NetConnection 192.168.1.20 -Port 443         # ¿responde esa IP en el puerto?

Si la prueba por IP funciona pero por nombre falla, el problema es de DNS (o de un archivo hosts que desvía el nombre). Si falla de las dos formas, el problema está en la red, el cortafuegos o el servicio. Esta separación te ahorra mucho tiempo y es la primera técnica de cualquier diagnóstico de conectividad.

Una limitación: la velocidad cuando el puerto está cerrado

Cuando el destino no responde o filtra el puerto, Test-NetConnection puede tardar varios segundos en dar por fallida la conexión, porque también resuelve el nombre y hace una prueba de ping previa. En listas largas esto se acumula. Si necesitas una prueba rápida con un tiempo máximo que controles, puedes usar la clase de .NET TcpClient:

function Test-Puerto {
    param([string]$Destino, [int]$Puerto, [int]$MilisegundosMaximo = 1500)
    $cliente = [System.Net.Sockets.TcpClient]::new()
    try {
        $tarea = $cliente.ConnectAsync($Destino, $Puerto)
        return ($tarea.Wait($MilisegundosMaximo) -and $cliente.Connected)
    }
    catch { return $false }
    finally { $cliente.Dispose() }
}

Test-Puerto -Destino 'servidor01' -Puerto 443

Evita llamar al parámetro $Host, porque es una variable automática de PowerShell, y por eso en el ejemplo se usa $Destino.

Lo que Test-NetConnection no hace

No prueba puertos UDP. Solo conexiones TCP. Para UDP existen otras herramientas (como PortQry), y muchos servicios UDP no responden a una prueba simple.
No verifica que el servicio funcione, solo que el puerto acepte conexiones. Un servidor web puede aceptar conexiones en el 443 y devolver un error; para comprobarlo, usa Invoke-WebRequest.
No es una medida de rendimiento. El tiempo del ping es orientativo; para medir ancho de banda hacen falta otras herramientas.

Equivalencias con las herramientas clásicas

ping → Test-NetConnection destino
telnet destino puerto → Test-NetConnection destino -Port puerto
tracert destino → Test-NetConnection destino -TraceRoute
nslookup nombre → Resolve-DnsName nombre
netstat -an → Get-NetTCPConnection

Casos prácticos de diagnóstico

«No puedo conectar por Escritorio remoto»: Test-NetConnection servidor -CommonTCPPort RDP. Si falla, el problema es de red o de cortafuegos, no de credenciales. Si quieres revisar la seguridad de ese servicio, consulta cómo proteger el Escritorio Remoto (RDP) en Windows Server.
«La web no carga»: Test-NetConnection sitio.com -Port 443 separa los fallos de red de los del servidor web.
«Un script remoto no funciona»: comprueba el 5985 (WinRM) antes de culpar al script.
«Una aplicación no encuentra la base de datos»: prueba el puerto de la base de datos desde el equipo cliente, no desde tu equipo.
Comprobación periódica: programa una prueba diaria de los servicios críticos con las tareas programadas de PowerShell y recibe un aviso si algo falla.

Preguntas frecuentes

¿Por qué ping falla pero el puerto responde?

Porque muchos cortafuegos y servidores bloquean ICMP por seguridad. Lo decisivo es la prueba del puerto del servicio que necesitas.

¿Necesito permisos de administrador?

Para las pruebas básicas de ping y de puerto no. Algunas opciones de diagnóstico de enrutamiento pueden requerir permisos elevados.

¿Puedo probar desde un equipo hacia otra red a través de un equipo intermedio?

La prueba se hace desde el equipo donde ejecutas el cmdlet. Para probar desde otro equipo, ejecuta el comando en él con Invoke-Command o una sesión remota.

Conclusión

Test-NetConnection sustituye a ping, telnet y tracert con una salida que puedes filtrar y automatizar. Aprende los tres usos esenciales (la prueba básica, -Port con TcpTestSucceeded y -TraceRoute), recuerda que un ping fallido no significa un servicio caído y usa -InformationLevel Quiet en tus scripts. Para listas largas o tiempos controlados, combínalo con un bucle o con la clase TcpClient.

Test-NetConnection: guía del cmdlet de PowerShell