Las desconexiones inesperadas en sesiones RDP pueden devastar la productividad diaria. Esta guía profundiza en las causas probables y describe una ruta de diagnóstico paso a paso, adaptada a entornos Windows Server 2022 con balanceadores Kemp LoadMaster.
Resumen del problema
Varios usuarios se desconectan aleatoriamente entre una y cuatro veces al día de dos servidores RDS Windows Server 2022 publicados tras dos unidades Kemp LoadMaster que balancean el puerto 3389. El uso medio de CPU y memoria no supera el 50 %, por lo que los síntomas apuntan a breves micro‑cortes de red. El Visor de eventos registra los códigos 0x80070079 (timeout de semáforo) y 0x80070040 (nombre de red no disponible), típicos de pérdidas de conectividad más que de problemas de licenciamiento o de sobrecarga del host.
Síntomas característicos
- Caída de la sesión y retorno automático a la pantalla de inicio de sesión.
- Mensaje “Se perdió la conexión con los servicios de Escritorio remoto” sin especificar causa.
- No se observan picos sostenidos en CPU, RAM ni disco durante la ventana de fallo.
- Los contadores de red muestran ráfagas de retransmisiones TCP justo antes de la desconexión.
Tabla de eventos comunes
| Código | Descripción breve | Causa probable |
|---|---|---|
| 0x80070079 | Se agotó el tiempo de espera del semáforo | Lentitud o corte de red |
| 0x80070040 | El nombre de red ya no está disponible | Pérdida de enlace o reset de sesión |
| 0xC000006F | Error de inicio de sesión | Credenciales/GPO expiradas |
| 0xC0000133 | Diferencia de reloj | Problemas de NTP o AD |
Principales hipótesis de causa
- Interrupciones intermitentes en la red física o virtual.
- Persistencia y health‑checks del LoadMaster configurados con timeouts agresivos.
- Bug conocido en la pila UDP de RDP solucionado mediante CU recientes.
- NIC offloading o RSS mal dimensionado que provoca drenaje del ring buffer.
- Firewall intermedio que cierra conexiones inactivas antes de tiempo.
Ruta rápida de diagnóstico
Actualizar y parchar todo el stack
Antes de profundizar, aplique la última cumulative update de Windows Server 2022, así como firmware y drivers de la NIC. Compruebe también que el hipervisor incluya parches de redings. Por su parte, revise el release fast‑track de Kemp LoadMaster y cargue la imagen LTS más reciente; varias versiones corrigen reinicios del canal UDP y problemas de persistencia de sesión.
Comprobar la red extremo a extremo
La meta es demostrar (o descartar) pérdida de paquetes entre los tres segmentos:
- Cliente ↔ LoadMaster
- LoadMaster ↔ Servidor RDS A
- LoadMaster ↔ Servidor RDS B
ping -n 500 -l 32 -4 <ip_destino>
pathping <ip_destino>
iperf3 -c <ip_destino> -t 120 -P 4
Anote la marca de tiempo exacta de cada desconexión y busque en los registros de switches y firewalls eventos de link‑flap, renegociación de velocidad, descartar de colas o sesiones TCP reseteadas.
Revisar configuración del balanceador
- Habilite persistencia de sesión basada en la cookie RDP (LoadMaster: Persistence Mode → Super HTTP) o por fuente IP cuando el NAT sea estático.
- Time‑out de inactividad: 60 s mínimo en TCP y UDP.
- Health‑check cada 10 s con tres reintentos antes de marcar el nodo como caído.
- Prueba A/B: permita a un subconjunto de usuarios conectarse directo al nodo RDS (sin LoadMaster). Si la incidencia no se reproduce, concentre la investigación en la red previa al balanceador.
Analizar eventos y habilitar registros detallados
Active los canales de diagnóstico RDS en cada servidor:
wevtutil sl Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /e:true
wevtutil sl Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational /e:true
wevtutil sl Microsoft-Windows-TerminalServices-RDPClientDR/Operational /e:true
Asimismo, capture contadores con perfmon:
- Network Interface → Bytes Total/sec, Output Queue Length
- TCPv4 → Segments Retransmitted/sec
- Process(es) → Interrupts/sec, DPCs Queued/sec
En el equipo cliente, consulte Visor de eventos → RemoteDesktopServices‑RdpCoreTS; si la caída nace allí, el problema puede ser la red WAN o el cliente RDP.
Ajustes de keep‑alive y sistema
Para evitar sesiones huérfanas por NAT o firewalls intermedios, configure:
[HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
"KeepAliveEnable"=dword:00000001
"KeepAliveTime"=dword:000493e0 ; 300 000 ms
Adicionalmente:
- Desactive redirección de impresoras y puertos si no se usa.
- Desactive la compresión UDP inicial (KB5014021 aborda un bug de fragmentación MTU).
- Verifique que ningún script de mantenimiento reinicie la pila QoS o realice flush de tablas ARP.
Descartar recursos insuficientes
El hecho de que CPU y RAM no superen el 50 % no descarta cuellos de botella puntuales. Añada contadores de disco (Average Disk sec/Transfer) y de red (Current Bandwidth). Los picos de ISR o DPC en valores >20 000/s indican que la NIC satura la cola de interrupciones; pruebe a elevar los RSS Queues o a desactivar Large Send Offload.
Pruebas opcionales
- Migre temporalmente una VM a otro host para descartar problemas de vSwitch.
- Fuerce RDP‑TCP (deshabilite UDP) editando la directiva Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections → Select RDP Transport Protocols.
- Si la estabilidad mejora, ajuste la MTU (1 320‑1 472) o retire jumbo frames en el tramo problemático.
Receta de monitorización continua
- Sysmon + Elastic o WEF para correlacionar eventos 21/24 (NetworkDisconnect).
- Grafana + Telegraf apuntando a los performance counters.
- Netsh trace con disparo circular (buffer 512 MB, máximo 30 min) y filtro
icmptunnel or rdp. - Tamper Proof Dashboards en LoadMaster para latencia por nodo.
Checklist final de corrección
| Paso | Estado | Fecha |
|---|---|---|
| Instalar CU más reciente en RDS | ✔ | |
| Actualizar firmware NIC y LOM | ||
| Aumentar idle timeout en LoadMaster | ||
| Activar KeepAlive en registro | ||
Ejecutar pruebas iperf3 | ||
| Deshabilitar UDP como test | ||
Revisar pathping entre segmentos | ||
Analizar netsh trace |
Conclusión y próximos pasos
Las desconexiones aleatorias rara vez obedecen a una única causa; suelen ser la suma de micro‑cortes de red, timeouts agresivos y errores de firmware. Si tras aplicar las actualizaciones, ajustar los keep‑alive y verificar la red no aparecen nuevas caídas en un periodo de al menos siete días laborables, considere el problema resuelto y documente la configuración como base de línea. Si persisten, profundice con capturas de paquetes simultáneas en cliente, LoadMaster y servidor; la correlación de sequence numbers revelará el eslabón donde se pierde la sesión.
Al dedicar tiempo a un diagnóstico metódico —primero eliminando variables obvias y después afinando parámetros— se minimiza el impacto en usuarios y se crea un historial valioso para futuras auditorías.