Cuando pensamos en el rendimiento de Parallels RAS, solemos centrarnos en el dimensionamiento de los RDSH, la optimización de los perfiles FSLogix o el ancho de banda. Pero hay un parámetro que suele pasar desapercibido y que, sin embargo, cambia radicalmente la experiencia del usuario: el protocolo de transporte de la sesión RDP. TCP o UDP: esta elección influye directamente en la fluidez de la sesión, sobre todo en redes imperfectas.
La buena noticia: Parallels RAS activa UDP por defecto. La no tan buena: varios elementos de tu entorno de red pueden desactivarlo sin que te enteres.
TCP frente a UDP: la analogía de Netflix
Para entender por qué UDP es preferible a TCP en una sesión RDP, piensa en Netflix. Netflix usa QUIC, un protocolo basado en UDP. ¿Por qué? Porque, cuando se pierden paquetes, QUIC sigue enviando los datos siguientes y corrige los errores sobre la marcha. Un microcorte de red se traduce en una ligera degradación de la imagen durante una fracción de segundo, imperceptible para el usuario.
Si Netflix usara TCP, cada pérdida de paquetes detendría por completo el flujo a la espera de la retransmisión. El vídeo se congela. El usuario espera. Es exactamente lo que ocurre con RDP en modo TCP: un microcorte de red congela la sesión, la pantalla se bloquea y el usuario llama al soporte. En modo UDP, RAS aplica un mecanismo de corrección de errores parecido al del streaming de vídeo y la sesión continúa sin interrupciones.
Los 4 modos de conexión de Parallels Client
- Gateway Mode (puerto 80 por defecto): el cliente pasa por el Secure Gateway sin cifrado SSL. Uso típico: red interna de confianza. UDP compatible.
- Gateway SSL Mode (puerto 443 por defecto): lo mismo, pero con cifrado SSL/TLS de extremo a extremo. UDP compatible mediante DTLS. Recomendado en producción.
- Direct Mode: el cliente se conecta directamente al RDSH sin pasar por el gateway. El broker solo se encarga de la redirección inicial. Reservado a la LAN con acceso directo a los RDSH.
- Direct SSL Mode: igual que Direct Mode, pero con cifrado SSL.
En producción, Gateway SSL Mode en el puerto 443 cubre todos los casos sin concesiones.
UDP activado por defecto en RAS
No tienes nada que configurar en RAS. El UDP Data Tunneling está activado por defecto tanto en el Secure Gateway como en el HALB.
En el Secure Gateway (pestaña Network), Enable RDP UDP Data Tunneling está marcado por defecto.
En el HALB (pestaña Advanced), Enable RDP UDP tunneling está en Enable por defecto.
Si nunca has tocado estos ajustes, UDP está activo. Punto.
Entonces, ¿por qué algunas sesiones se quedan en TCP?
La respuesta está siempre en el entorno de red que rodea a RAS, nunca en RAS. Estos son los dos principales culpables.
El DNS: la trampa más habitual
Un Parallels Client configurado con el FQDN externo ras.client.com en Gateway SSL Mode resolverá ese FQDN a la IP pública mediante el DNS público cuando esté en la LAN. El cliente sale por el camino externo y el resultado es TCP. La solución: crear un registro DNS interno que apunte ras.client.com a la VIP de la LAN. Mismo FQDN, mismo certificado: el DNS hace el reparto. UDP se negocia de inmediato.
Un firewall que filtra UDP/443
El puerto UDP 443 debe estar abierto en todo el camino entre el cliente y el Secure Gateway, incluidos los firewalls intermedios y el HALB. Un firewall configurado para dejar pasar solo TCP/443 obliga en silencio al cliente a quedarse en TCP.
Configuración de cliente recomendada en producción
- Conexión principal:
ras.client.com, Gateway SSL Mode, puerto 443. En la LAN, el DNS interno resuelve a la VIP de la LAN → UDP activo, latencia mínima. - Conexión secundaria:
ras.client.com, Gateway SSL Mode, puerto 443. Desde fuera, el DNS público resuelve a la IP pública → Gateway SSL, con UDP si el firewall lo permite.
Mismo FQDN, mismo certificado, misma configuración de cliente. El DNS hace todo el trabajo.
Resultados medidos
Caso 1: TCP con DNS público y camino no óptimo
Gateway Mode, DNS público que resuelve a la IP externa. Transporte: TCP, latencia de 35 ms, calidad Good.
Caso 2: UDP en la LAN con conexión directa
Cliente Windows conectado directamente en la LAN en Gateway Mode. Transporte: UDP, latencia de 1 ms, calidad Excellent, 11 Mbps disponibles.
Caso 3: UDP en Gateway SSL Mode a través de VPN
Cliente Mac por VPN, Gateway SSL Mode, DNS interno correctamente distribuido. Transporte: UDP, latencia de 42 ms, calidad Good, 8,4 Mbps.
Caso 4: UDP desde Internet con UDP/443 abierto
Cliente Mac desde Internet sin VPN, Gateway SSL Mode, UDP/443 abierto en el router. Transporte: UDP, latencia de 36 ms, calidad Good, 7,8 Mbps.
Resumen
| Contexto | Modo | Transporte | Latencia | Calidad | Ancho de banda |
|---|---|---|---|---|---|
| DNS público, camino no óptimo | Gateway Mode | TCP | 35 ms | Good | 5 Mbps |
| LAN directa | Gateway Mode | UDP | 1 ms | Excellent | 11 Mbps |
| Por VPN + DNS interno | Gateway SSL Mode | UDP | 42 ms | Good | 8,4 Mbps |
| Externo, UDP/443 abierto | Gateway SSL Mode | UDP | 36 ms | Good | 7,8 Mbps |
Lista de comprobación para garantizar UDP
- UDP activado en el Secure Gateway: activo por defecto ✅
- UDP activado en el HALB: activo por defecto ✅
- UDP/443 abierto en los firewalls entre el cliente y el SG
- DNS interno que resuelva el FQDN de RAS a la VIP de la LAN para los clientes internos
- Gateway SSL Mode configurado en Parallels Client (puerto 443)
- Certificado válido para el FQDN utilizado
Conclusión
En Parallels RAS, UDP no es una opción que haya que activar: es el comportamiento por defecto. Tu trabajo como administrador es asegurarte de que nada en tu entorno de red lo bloquee en silencio. Un DNS interno bien configurado, un firewall que deje pasar UDP/443 y un certificado válido: no hace falta más para que tus usuarios disfruten de sesiones RDP fluidas, incluso en redes imperfectas.
