¿RDP se detiene tras instalar un cliente VPN? Es el firewall

Pocos minutos después de que un cliente VPN de consumo termine de instalarse, el portal sigue diciendo que la VM está en marcha, la IP pública no ha cambiado y RDP no responde. La gente suele suponer que la VM se ha caído o que ha cambiado el grupo de seguridad de red, y ambas cosas suelen ser falsas. Lo que ha cambiado es el perfil del firewall de Windows en el que está la máquina, y la regla de RDP que antes coincidía ya no coincide. La reparación empieza por obtener un shell por una vía que no dependa de RDP.

La VM está en marcha; la regla dejó de coincidir

Las reglas del firewall de Windows llevan un conjunto de perfiles, y una regla limitada a Privado o Dominio no tiene efecto mientras la máquina está en el perfil Público. Los instaladores de VPN añaden adaptadores y rutas, y varios endurecen el Público como efecto secundario. El escucha sigue ligado al 3389 y los paquetes siguen llegando, pero el desajuste de perfil los descarta.

El estado de energía y la accesibilidad son hechos distintos, y una VM en marcha con un puerto cerrado se ve desde fuera exactamente como una caída.

Pruebe el puerto antes de tocar nada. Un intento de conexión al 3389 que expira mientras un comando del agente invitado sigue devolviendo salida apunta al firewall del host. Un puerto que responde mientras RDP sigue fallando significa que el fallo está por encima de la capa de red, y esta reparación no lo tocará. Anote cuál de los dos casos ha visto, porque el resto del plan depende de ello.

Dos puertas se cierran de forma independiente

La política de la plataforma va primero: el grupo de seguridad de red ve el paquete antes que el invitado. Ese orden hace inútil una entrada de NSG perfecta cuando el host descarta el paquete, e inútil una regla de host abierta cuando la plataforma la deniega. Trátelos como puertas separadas y pruebe cada una por su cuenta.

Lea las reglas efectivas del NSG en el portal o en la CLI y luego compárelas con las reglas propias del invitado. No suponga que el último cambio que recuerda es el que ha entrado en vigor.

Un cliente de consumo también puede instalar un controlador de filtro o un interruptor de emergencia que bloquee el tráfico por debajo del firewall de Windows. Si las reglas del firewall parecen correctas y el puerto sigue fallando, esa capa es el siguiente sospechoso.

Use el agente invitado como vía de vuelta

Dos funciones de ejecución remota, Run Command y la Custom Script Extension, se ejecutan dentro del invitado mediante el agente de la plataforma. Ninguna necesita RDP, así que el error del firewall no las afecta. Ambas devuelven la salida del script, lo que las convierte en canal de diagnóstico y también de reparación.

Lea el perfil activo y la regla de RDP antes de cambiar cualquiera de los dos:

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

Reactivar las reglas de entrada en ese perfil es una medida temporal, no un destino. Úsela para conseguir una sesión y luego cierre el hueco correctamente:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

Ese interruptor abre todas las reglas de entrada del perfil, no solo RDP. Cuando tenga una sesión, sustitúyalo por una regla limitada y restaure los ajustes que realmente quiere. Si el agente tampoco está disponible, la alternativa es una consola serie o un disco reconstruido, y esa es la razón práctica para mantener el agente sano.

Estreche el hueco antes de cerrar la sesión

El cambio temporal de perfil es una puerta abierta a todas las reglas de entrada de ese perfil. Sustitúyalo por una regla limitada a su dirección de origen y al puerto RDP, y luego confirme que el perfil ha vuelto a su estado previsto. Hágalo mientras aún tiene la sesión, porque el siguiente error puede no ser reversible en remoto. Mantenga una segunda vía administrativa como Bastion o una consola serie durante el cambio.

Confirme el resultado desde su estación de trabajo con una prueba de puerto, y desde dentro del invitado con la lista de reglas:

Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter

Active el registro del firewall durante la prueba. Una sola línea de paquete descartado que nombre el 3389 y el perfil activo responde la pregunta más rápido que otro reinicio.

Evite que el siguiente instalador lo vuelva a hacer

Si ese host no tiene motivo para ejecutar el cliente, desinstálelo. Un cliente instalado es una invitación permanente a que la próxima actualización reescriba el perfil otra vez, y la siguiente persona depurará la misma caída desde el portal.

Haga una instantánea del disco antes de dejar que algo reescriba la configuración de red, y tenga una segunda vía administrativa lista antes de necesitarla.

Anote qué modificó el instalador: adaptadores, rutas, perfiles de firewall, controladores de filtro y servicios. Ese registro convierte el siguiente incidente en un patrón conocido en lugar de una investigación nueva. Cuando la VM necesite un túnel hacia exactamente un servicio, ponga el cliente en su estación de trabajo o monte un enlace sitio a sitio en vez de instalar en el servidor un producto para portátiles. Los clientes de consumo apuntan a portátiles, y un servidor que administra en remoto no lo es.