ESC

Start typing to search across invoices, services, domains, tickets, and more...

Search... Ctrl+K
Windows Server

Cómo solucionar errores de Escritorio remoto (RDP) en Windows

6 pasos 16 min de lectura 1793 vistas 49
Contenido

Uno de los problemas más comunes tras desplegar un VPS o un servidor dedicado con Windows es que falla la conexión de Escritorio remoto (RDP): el cliente indica que "no se puede conectar al equipo remoto", se queda colgado indefinidamente o muestra un error de autenticación CredSSP / NLA. Esta guía le acompaña en la solución de problemas de RDP de fuera hacia dentro —puerto 3389, Firewall de Windows, Servicios de Escritorio remoto, autenticación a nivel de red (NLA) y credenciales de la cuenta— en Windows Server 2016, 2019 y 2022.

Asegúrese de que el servidor esté encendido y de que no se acabe de reinstalar o reiniciar. Una instalación nueva o una actualización pendiente pueden retrasar la disponibilidad de RDP entre 5 y 15 minutos.

Paso 1: Compruebe si el puerto RDP 3389 es accesible

Desde su equipo local, haga ping al servidor y luego pruebe el puerto de Escritorio remoto. Muchos servidores bloquean ICMP, por lo que un ping fallido por sí solo no significa que el servidor esté caído: lo que importa es la prueba del puerto. En PowerShell, en su PC local con Windows, ejecute:

ping 203.0.113.10
Test-NetConnection 203.0.113.10 -Port 3389

Si ve TcpTestSucceeded : True, el puerto está abierto y lo más probable es que el problema sea de autenticación o de la cuenta. Si aparece False, continúe con las comprobaciones del servicio y del firewall que se indican a continuación. En macOS o Linux puede usar nc -vz 203.0.113.10 3389. Si cambió anteriormente el puerto RDP, pruebe ese puerto y conéctese usando IP:port.

Paso 2: Inicie sesión a través de la consola VNC

No necesita reinstalar el sistema operativo cuando falla RDP. Inicie sesión en el área de cliente de IMIDC → My Products & Services (Mis productos y servicios) → seleccione su servidor → Manage (Administrar) y abra la consola VNC (los servidores dedicados suelen ofrecer IPMI/KVM). Así obtendrá una sesión equivalente a la pantalla local para reparar Windows. Si no encuentra la consola, abra un ticket de soporte y nuestro equipo le ayudará.

Paso 3: Asegúrese de que los Servicios de Escritorio remoto están activados y escuchando

En la consola VNC, abra PowerShell como administrador y compruebe si el Escritorio remoto está desactivado, si el servicio TermService se está ejecutando y si el puerto 3389 está a la escucha:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
Get-Service TermService
netstat -ano | findstr :3389

Un valor de 0x1 en fDenyTSConnections significa que el Escritorio remoto está desactivado. Vuelva a activarlo y reinicie el servicio:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections -Value 0
Set-Service TermService -StartupType Automatic
Restart-Service TermService -Force

Paso 4: Revise las reglas de Escritorio remoto del Firewall de Windows

Un firewall o una herramienta de seguridad que bloquea el puerto 3389 es una causa muy frecuente de fallos de RDP. Los siguientes comandos usan el nombre de grupo de reglas independiente del idioma, por lo que funcionan tanto en ediciones de Windows en inglés como en ediciones localizadas (por ejemplo, en español):

Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"
Get-NetFirewallRule -Group "@FirewallAPI.dll,-28752" | Select-Object DisplayName, Enabled, Profile

Si instaló software de seguridad de terceros, revise también su configuración de bloqueo de puertos y de lista negra de IP. Para confirmar si el firewall es el culpable, puede desactivarlo brevemente y volver a activarlo inmediatamente después:

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

Paso 5: Corrija los errores de autenticación NLA y CredSSP

El mensaje "An authentication error has occurred. The function requested is not supported… This could be due to CredSSP encryption oracle remediation" (en Windows en español: "Se produjo un error de autenticación. No se admite la función solicitada… Esto puede deberse a la corrección de oráculo de cifrado de CredSSP") significa que su PC y el servidor tienen niveles de parches de seguridad diferentes. La solución correcta es actualizar completamente ambos lados. Si no puede actualizar el servidor de inmediato, ejecute lo siguiente en su PC local como administrador como solución temporal:

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /f /v AllowEncryptionOracle /t REG_DWORD /d 2

Si la autenticación a nivel de red (NLA) está bloqueando el inicio de sesión, desactívela temporalmente en el servidor desde la consola VNC:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name UserAuthentication -Value 0
Desactivar NLA y relajar CredSSP debilitan la seguridad. Una vez que haya vuelto a entrar y se haya ejecutado Windows Update, restablezca UserAuthentication a 1 y elimine el valor AllowEncryptionOracle de su PC.

Paso 6: Verifique la cuenta y las credenciales

Si ve "Your credentials did not work" (Sus credenciales no funcionaron) o "The logon attempt failed" (Error en el intento de inicio de sesión), compruebe que el nombre de usuario sea Administrator (o la cuenta que haya creado), recuerde que las contraseñas distinguen entre mayúsculas y minúsculas y evite copiar espacios al final. Los intentos fallidos repetidos pueden bloquear la cuenta. Restablezca la contraseña y desbloquee la cuenta desde la consola VNC:

net user Administrator *
net user Administrator /active:yes
net accounts

net user Administrator * le pide la nueva contraseña dos veces (no se muestra nada en pantalla). Además, Windows Server solo permite por defecto dos sesiones de administración simultáneas; si están en uso, enumérelas con query session y cierre una con logoff <session ID>.

Preguntas frecuentes

RDP se conecta pero se desconecta a los pocos segundos. ¿Por qué?

Normalmente se debe a pérdida de paquetes, a un servidor que se queda sin CPU o memoria, o a una directiva de tiempo de espera de sesión. Revise el uso de recursos en Task Manager (Administrador de tareas) y ejecute ping -t <server IP> en su equipo local para detectar pérdidas de paquetes continuas.

El servidor no responde al ping. ¿Está caído?

No necesariamente. El Firewall de Windows suele bloquear ICMP de forma predeterminada. Si Test-NetConnection tiene éxito en el puerto 3389, el servidor está en línea.

RDP solo falla desde la red de mi oficina. ¿Qué puedo hacer?

Es posible que su proveedor de internet o la red corporativa bloqueen el puerto 3389, o que el software de seguridad del servidor haya incluido su IP en una lista negra. Pruebe a cambiar el puerto RDP o revise la lista negra de IP del servidor.

Si ninguno de los pasos anteriores resuelve el problema, envíe un ticket de soporte al soporte técnico 24/7 de IMIDC con la IP de su servidor, una captura de pantalla del error y los pasos que ya ha probado.

¿Fue útil la respuesta?

Tutoriales relacionados