Por qué se congela el RDP cuando el equipo remoto se conecta a una VPN

Estás dentro de la ventana de RDP, el escritorio está en pantalla y pulsas Connect en el cliente VPN que se ejecuta en ese equipo remoto. Segundos después la ventana se congela y luego se cierra. El túnel se levantó, que es exactamente lo que registrará el log de la VPN, y ese es el dato menos útil de todo el incidente. La sesión murió porque la máquina con la que hablabas cambió la forma en que te responde, así que revisa el camino de vuelta antes de tocar el túnel.

Anota el extremo que tu sesión usa realmente

La dirección que escribes en tu cliente RDP no es necesariamente la dirección a la que responde el equipo remoto. El NAT, una RD Gateway o un balanceador de carga delante del host pueden reescribirla, y el camino de vuelta lo define la dirección de origen que la máquina remota ve en la conexión establecida. Si te equivocas aquí, buscarás una ruta que nunca estuvo implicada.

En el equipo remoto, antes de que la VPN esté conectada, lista las sesiones establecidas y lee la dirección del par de la tabla. Luego anótala en algún lugar fuera de esa máquina, porque no podrás leerla cuando caiga la sesión.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

Trata esa dirección como aquello que debe seguir siendo alcanzable. Si es una dirección privada en una VLAN de gestión, el túnel tiene que dejar ese camino en paz. Si es una dirección pública, la respuesta tiene que salir por la misma interfaz que trajo la petición.

Lee la ruta que responde a ese extremo

Windows elige una interfaz por destino, y Find-NetRoute muestra la decisión que tomaría ahora mismo. Ejecútalo contra la dirección del par antes de conectar, luego otra vez con el túnel levantado, y compara el índice de interfaz y el siguiente salto en las dos respuestas. Un cambio de interfaz es todo el fallo en una línea de salida.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

Un perfil de túnel completo instala una ruta por defecto a través del túnel, como describe la guía de enrutamiento de VPN de Windows, así que ahora cada respuesta sale por la VPN y depende de que el otro lado enrute de vuelta hacia tu cliente. Un perfil de túnel dividido es más seguro por defecto pero no inmune, porque una ruta específica que cubra la dirección del par todavía puede vencer a la ruta por defecto física. En cualquier caso la pregunta es idéntica: cuando el túnel se levanta, ¿la dirección del par sigue resolviendo a la interfaz que trajo la sesión?

Si no, la corrección pertenece al perfil o a una ruta de excepción explícita aprobada por quien posee la política de VPN. Editar la tabla de enrutamiento a mano en un host de producción durante un incidente es cómo un apaño temporal se convierte en configuración no documentada.

Vigila el cambio de perfil del firewall

Una interfaz nueva se clasifica cuando aparece, y la clasificación decide contra qué perfil de firewall se juzga su tráfico. Un adaptador de túnel que cae en la categoría Public puede detener silenciosamente el RDP entrante aunque la tabla de enrutamiento parezca perfecta. Ese es el segundo modo de fallo, y produce un síntoma distinto: la ruta es correcta, los paquetes llegan y el host rechaza la conexión.

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

Compara el perfil asociado a la interfaz del túnel con los perfiles a los que están dirigidas las reglas de Remote Desktop. Una regla habilitada solo para Domain y Private no hace nada por una interfaz clasificada como Public, y ninguna corrección de ruta lo cambia. Algunos clientes VPN también restringen por diseño el acceso a la subred local, lo que produce la misma forma de fallo desde otro control.

Prueba la transición desde algún lugar recuperable

Haz toda la secuencia desde una consola fuera de banda o un segundo camino de gestión, en este orden: confirma la sesión existente, conecta la VPN, abre una sesión nueva, después desconecta la VPN y abre otra. Cada paso prueba una transición distinta, y el primero que falla te dice qué control es el responsable.

Programa la reversión antes de empezar, por ejemplo una tarea programada que ejecute rasdial "Work VPN" /disconnect tras un intervalo fijo. Eso convierte una sesión perdida en una interrupción de cinco minutos en lugar de una visita al sitio, y es el seguro más barato de todo el procedimiento.

Vuelve a entrar cuando la sesión ya se ha ido

Si el host ya es inalcanzable, deja de probar conexiones RDP nuevas desde el mismo cliente y usa el canal de recuperación que el entorno ya tiene: una RD Gateway, una consola de hipervisor o una interfaz de gestión fuera de banda. Pide a la persona con acceso a la consola que ejecute los mismos comandos Find-NetRoute y Get-NetConnectionProfile, para que las pruebas sobrevivan a la recuperación.

Luego decide el arreglo permanente en lugar del más rápido. O el camino de gestión se preserva explícitamente en el perfil de VPN, o la gestión pasa a un canal que no depende de la ruta por defecto del host. Ambos son sostenibles; una ruta de host con una puerta de enlace adivinada no lo es. Anota cuál elegiste y registra la dirección del par que tenía que sobrevivir.