Test-NetConnection: probar puertos remotos y conectividad en PowerShell

El servidor del cliente responde al ping, pero la aplicación no abre. ¿El puerto 443 está realmente permitido en el firewall? En lugar de instalar telnet — que Microsoft eliminó de Windows por defecto — o depender del ping que solo prueba ICMP, PowerShell ofrece un cmdlet que hace todo eso a la vez: Test-NetConnection. Un comando reemplaza ping, telnet y traceroute, y entrega la salida como objeto que puedes filtrar y automatizar.
¿Qué es Test-NetConnection?
Test-NetConnection forma parte del módulo NetTCPIP, disponible por defecto en Windows 8.1/Server 2012 R2 y versiones posteriores. Prueba cuatro cosas en una sola ejecución:
- Resolución DNS del hostname
- Alcanzabilidad ICMP (equivalente al
ping) - Conectividad TCP en un puerto específico (equivalente al antiguo
telnet host puerto) - Ruta de red hasta el destino (
-TraceRoute)
La salida es un objeto PowerShell — no texto plano — lo que significa que puedes filtrar por propiedad, comparar resultados e integrar en scripts de monitoreo sin necesidad de analizar cadenas de texto.
Sintaxis básica
Test-NetConnection -ComputerName "host-o-ip" -Port 443Los parámetros más utilizados:
-ComputerName: hostname o IP de destino-Port: puerto TCP a probar-CommonTCPPort: atajo para puertos conocidos — aceptaHTTP,HTTPS,RDP,SMB,WINRM-TraceRoute: activa el rastreo de ruta-InformationLevel:Detailed(salida completa) oQuiet(retorna solo True/False — ideal para scripts)
Cómo probar si un puerto está abierto en un servidor remoto
¿Cómo saber si un puerto TCP está abierto en un servidor remoto?
Ejecuta Test-NetConnection -ComputerName "servidor" -Port 443 en PowerShell. Si TcpTestSucceeded devuelve True, el puerto es accesible. Si devuelve False, el puerto está cerrado o un firewall está bloqueando el tráfico.
Ejemplo práctico probando HTTPS en un servidor web:
Test-NetConnection -ComputerName "miservidor.empresa.com" -Port 443Salida típica:
ComputerName : miservidor.empresa.com
RemoteAddress : 10.0.0.50
RemotePort : 443
InterfaceAlias : Ethernet
SourceAddress : 10.0.0.10
TcpTestSucceeded : TrueEl campo clave para el diagnóstico rápido es TcpTestSucceeded. Ten en cuenta que un firewall que responde con RST devolverá False de inmediato; uno que descarta paquetes silenciosamente (DROP en lugar de REJECT) tardará hasta agotar el tiempo de espera antes de devolver False.
Ejemplos prácticos por caso de uso
Probar acceso RDP (puerto 3389)
Antes de intentar conectar por Remote Desktop, confirma que el servicio responde en el puerto correcto. Si quieres ir más lejos y bloquear fuerza bruta en RDP, consulta cómo proteger el RDP contra ataques de fuerza bruta.
Test-NetConnection -ComputerName "192.168.1.100" -CommonTCPPort RDPProbar SMB (puerto 445) antes de mapear una unidad de red
Test-NetConnection -ComputerName "fileserver" -CommonTCPPort SMBVerificar si el servicio HTTP está activo
Test-NetConnection -ComputerName "intranet.empresa.com" -CommonTCPPort HTTPModo silencioso para scripts y monitoreo
El parámetro -InformationLevel Quiet hace que el cmdlet devuelva directamente True o False, sin la salida formateada. Perfecto para condicionales en scripts:
if (Test-NetConnection -ComputerName "api.empresa.com" -Port 8080 -InformationLevel Quiet) {
Write-Output "Servicio disponible"
} else {
Write-Output "ATENCIÓN: puerto 8080 inaccesible"
# Enviar alerta, registrar en log, etc.
}Combínalo con un array de hosts para un escáner rápido de disponibilidad:
$hosts = @("web01", "web02", "api01", "db01")
foreach ($h in $hosts) {
$status = if (Test-NetConnection -ComputerName $h -Port 443 -InformationLevel Quiet) { "OK" } else { "FALLÓ" }
Write-Output "$h : $status"
}Esto es mucho más limpio que analizar la salida de ping o netstat. Si también quieres inspeccionar lo que está escuchando localmente, el cmdlet complementario es Get-NetTCPConnection, que lista todas las conexiones y puertos abiertos en la máquina local.
Rastreo de ruta con PowerShell
El parámetro -TraceRoute muestra cada salto entre tu máquina y el destino, equivalente al clásico tracert — pero con salida en objeto:
Test-NetConnection -ComputerName "8.8.8.8" -TraceRouteLa salida incluye el campo TraceRoute con la lista de IPs intermedias. Si un salto tarda mucho o aparece como *, ahí es donde el tráfico se está deteniendo. Útil para identificar cuellos de botella en la red o confirmar que el enrutamiento pasa por el camino esperado.
Verificar si un servicio Windows está activo antes de probar el puerto
A veces el puerto está cerrado simplemente porque el servicio no está en ejecución. Combina la prueba de puerto con una verificación local del servicio para llegar más rápido a la causa. Get-Service se encarga de esa parte:
# Verificar si W3SVC (IIS) está corriendo antes de probar el puerto 80
if ((Get-Service -Name W3SVC).Status -ne "Running") {
Write-Warning "IIS está detenido — inicia el servicio antes de probar"
} else {
Test-NetConnection -ComputerName "localhost" -Port 80
}Consideraciones de seguridad
Test-NetConnection también es útil para auditar la segmentación de red: prueba desde una VLAN de usuarios si los puertos administrativos (como RDP/3389 o WinRM/5985) de servidores son accesibles cuando no deberían serlo. Si TcpTestSucceeded: True en una combinación que viola tu política de firewall, tienes una regla mal configurada que corregir — y lo descubriste sin salir de la línea de comandos.
Si estás empezando con PowerShell y quieres entender los fundamentos antes de los cmdlets de red, el artículo PowerShell para principiantes cubre las bases necesarias.
Conclusión
Test-NetConnection es uno de los cmdlets más prácticos del arsenal de cualquier sysadmin Windows: prueba ping, puerto TCP y ruta en un solo comando, devuelve objetos filtrables y funciona sin instalar nada. Si sospechas un problema de conectividad entre sistemas, esta debe ser la primera herramienta que uses — antes de revisar el firewall, antes de llamar al proveedor, antes de cualquier otra cosa.
Si quieres profundizar en el diagnóstico de red con PowerShell, vale explorar también Get-NetTCPConnection para mapear conexiones abiertas en la máquina local.




Comentarios