Cómo configurar una puerta de enlace de Escritorio remoto en Windows Server

Cómo configurar y solucionar problemas de la puerta de enlace de Escritorio remoto en Windows Server

Si intenta implementar la Puerta de Enlace de Escritorio Remoto (RD Gateway) pero experimenta problemas, no está solo. A veces, el proceso de configuración es un poco confuso, sobre todo al gestionar certificados SSL y políticas, y al asegurarse de que sus clientes puedan conectarse sin problemas. Esta guía le ayudará a desentrañar algunos de estos problemas, para que, ya sean políticas poco claras o errores de certificado, tenga una idea más clara de qué podría estar mal y cómo solucionarlo. Al final, obtendrá una configuración de acceso remoto más segura y fiable que realmente funciona cuando la necesita.

Implementación de la función RDS-Gateway en Windows Server

Método 1: Instalación mediante el Administrador del servidor o PowerShell

Normalmente, se empieza por asegurarse de que el rol de Puerta de enlace de Escritorio remoto esté instalado en un servidor dedicado o junto con otros roles de RDS. En la mayoría de las configuraciones, usar PowerShell es más rápido, ya que Windows, por supuesto, tiene que complicarlo más de lo necesario. Si Active Directory y RDS ya están implementados, solo es cuestión de instalar el rol de puerta de enlace y configurarlo.

Para comprobar si el rol ya está instalado, ejecute esto en PowerShell:

Get-WindowsFeature RDS-Gateway

Si no está allí, instálalo con:

Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature -IncludeManagementTools

Esto también activará los roles de IIS y NPS, lo que permitirá que el paquete completo se ejecute. Una vez instalado, deberá crear grupos de acceso en Active Directory mediante ` dsa.msc`, como se indica a continuación:

• rdgwExtUsers — para usuarios autorizados a autenticarse;
• rdgwExternalAdmins : para usuarios que pueden conectarse a hosts RDS internos;
• mun-rdsfarm : todos los hosts RDS y el agente de conexión a Escritorio remoto a los que desea acceder a través de la puerta de enlace.

Método 2: Uso de la GUI y PowerShell para políticas

Una vez instalado el rol, el siguiente paso es configurar las políticas de autorización en el Administrador de Puerta de Enlace de Escritorio Remoto (`tsgateway.msc`).Cree una Política de Autorización de Conexión (CAP de Escritorio Remoto) —considere esto como quién accede— y una Política de Autorización de Recursos (RAP de Escritorio Remoto) —a qué servidores internos pueden acceder. La configuración predeterminada suele funcionar para pruebas, pero tenga cuidado con problemas comunes, como grupos de usuarios incorrectos o recursos de red no coincidentes.

Por ejemplo, crear una CAP de RD para sus usuarios externos podría implicar elegir un grupo como rdgwExtUsers y configurar la autenticación solo con contraseña o tarjeta inteligente. No olvide especificar las opciones de redirección de dispositivos y los tiempos de espera de las sesiones, ya que a veces las sesiones se bloquean sin motivo alguno.

Si prefieres PowerShell, aquí tienes un ejemplo rápido del CAP:

Import-Module -Name RemoteDesktopServices New-Item -Path 'RDS:\GatewayServer\CAP' -Name 'rdgwAllowAutht-CAP' -UserGroups rdgwExtUsers -AuthMethod '1'

De manera similar, cree el RAP para acceso interno, utilizando la GUI o PowerShell, como:

New-Item -Path RDS:\GatewayServer\RAP -Name allowextAdminMunRDS -UserGroups "rdgwExternalAdmins" -ComputerGroup "mun-rdsfarm" -Port 3389

Solución 1: Configuración del certificado SSL: asegúrese de que la conexión sea segura

Añadir un certificado SSL sólido es fundamental. No solo cifra los datos, sino que los clientes no se conectarán si el certificado SSL no es de confianza. Puedes optar por un certificado autofirmado (si estás haciendo pruebas), pero suele causar problemas de confianza. Normalmente, es mejor contar con un certificado auténtico de una CA (como Let’s Encrypt o un proveedor de pago), sobre todo si los clientes están fuera de tu dominio.

Dirígete a la consola de Puerta de enlace de Escritorio remoto, abre la pestaña Certificado SSL e importa tu certificado de confianza o crea uno autofirmado. Recuerda incluir el FQDN de tu servidor en el Nombre del sujeto o en los SAN; de lo contrario, los clientes recibirán errores por discrepancias en los nombres.

Los puertos 443 (TCP) y 3391 (UDP) deben estar abiertos en su firewall, dirigiendo el tráfico público a su servidor de Puerta de Enlace de Escritorio Remoto.¡Porque, claro, Windows lo complica!

Solución 2: Configurar correctamente el cliente RDP

Una vez configurado todo en el servidor, el cliente necesita algunos ajustes. Ejecute ` mstsc.exe` y, en la pestaña «Avanzado», haga clic en » Configuración » en «Conectarse desde cualquier lugar».

• Establezca el nombre de host del servidor de puerta de enlace de Escritorio remoto (por ejemplo, gw.yourdomain.com ); debe coincidir con el que figura en el certificado SSL.
• Si utilizó un puerto diferente, especifíquelo después del nombre de host, como gw.yourdomain.com:4443.
• Marque “Usar mis credenciales de RD Gateway para la computadora remota” para evitar problemas de inicio de sesión.

Tenga cuidado, si su certificado es autofirmado, deberá importarlo al almacén de Autoridades de Certificación Raíz de Confianza en el cliente; de ​​lo contrario, la conexión se bloqueará con errores. En algunas configuraciones, esto sigue siendo un problema, especialmente si trabaja con muchos usuarios remotos o con políticas de seguridad estrictas.

Solución 3: Solución de errores de conexión: Causas comunes

Si las conexiones no se realizan, verifique lo siguiente:

• Asegúrese de que los nombres del certificado SSL coincidan perfectamente con el nombre DNS utilizado por el cliente. Las discrepancias provocan fallos de conexión («Su equipo no puede conectarse…»).
• Verifique que los puertos estén abiertos y redireccionados correctamente. Ejecute `netstat -an` en el servidor para comprobar si los puertos 443 y 3391 están escuchando.
• Verifique las reglas de su firewall: reglas de entrada para TCP 443/3391 y reglas de salida que permiten el tráfico de retorno;
• Busque en los registros del Visor de eventos en Registros de aplicaciones y servicios > Microsoft > Windows > TerminalServices-Gateway identificadores como 205 para confirmar conexiones exitosas o errores.
• Asegúrese de que sus clientes confíen en el certificado SSL, especialmente si utilizó certificados autofirmados. A veces, importar el certificado raíz a los clientes soluciona el problema.

La mayoría de los problemas se deben a nombres DNS no coincidentes, redireccionamiento de puertos incorrecto o certificados no confiables. Son errores menores, pero bloquean todos los intentos de acceso remoto.

Solución 4: Ejecutar la puerta de enlace de Escritorio remoto sin AD (configuración de grupo de trabajo)

No se preocupe si no está en un dominio. Puede implementar la Puerta de enlace de Escritorio remoto en un entorno de grupo de trabajo, pero deberá realizar una configuración manual adicional. Instale el rol mediante PowerShell:

Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature -IncludeManagementTools

Abra el Administrador de Puerta de Enlace de Escritorio Remoto y cree las políticas necesarias, como antes. Asegúrese de configurar un certificado SSL adecuado: uno autofirmado funciona, pero uno a largo plazo facilita la vida a los clientes.

Para mayor seguridad, abra PowerShell y genere un certificado autofirmado con más SAN, especialmente si su nombre de host o IP cambian:

$todaydate = Get-Date $addyear = $todaydate. AddYears(5) New-SelfSignedCertificate -dnsname gw1.yourdomain.com, 10.11.12.13, rdgw.yourdomain.com -notafter $addyear -CertStoreLocation cert:\LocalMachine\My

Este certificado debe importarse al almacén personal y asignarse en las propiedades de la puerta de enlace de Escritorio remoto, en la pestaña Certificado SSL. Además, exporte el certificado (sin clave privada) para instalarlo en los clientes, de modo que confíen en la puerta de enlace.

Resumen

Poner en funcionamiento la Puerta de Enlace de Escritorio Remoto puede ser un poco complicado, especialmente con certificados y políticas SSL. Pero una vez configurada correctamente, supone una gran mejora respecto a exponer RDP directamente a internet. Simplemente revise las discrepancias de nombres y asegúrese de que los puertos estén abiertos y redireccionados correctamente. Después, todos los problemas de conexión del cliente suelen solucionarse.

Resumen

• Rol de puerta de enlace RDS instalado a través de PowerShell o el Administrador del servidor
• Políticas de autorización configuradas y redirección de dispositivos
• Se instalaron certificados SSL de confianza y se abrieron los puertos necesarios (443/3391)
• Clientes RDP configurados con nombres de servidor y certificados correctos
• Se revisaron los registros del Visor de eventos para verificar el éxito o errores de conexión

Cruzo los dedos para que esto ayude.

Mantén siempre tus certificados SSL actualizados y revisa bien el DNS y los puertos si algo no funciona. Con suerte, esto te ahorrará algunas horas de pruebas; es algo que funcionó en varias configuraciones, ¡así que inténtalo!