RDP Shortpath establece un transporte basado en UDP entre un dispositivo local, Aplicación de Windows o la aplicación de Escritorio remoto en plataformas compatibles y el host de sesión en Azure Virtual Desktop. De forma predeterminada, el Protocolo de escritorio remoto (RDP) comienza un transporte de conexión inversa basado en TCP y, a continuación, intenta establecer una sesión remota mediante UDP. Si la conexión UDP se realiza correctamente, la conexión TCP se interrumpe, de lo contrario, la conexión TCP se utiliza como mecanismo de conexión de reserva.
El transporte basado en UDP ofrece una mayor confiabilidad de conexión y una latencia más consistente. El transporte de conexión inversa basado en TCP proporciona la mejor compatibilidad con varias configuraciones de red y tiene una alta tasa de éxito para establecer conexiones RDP.
RDP Shortpath se puede usar de dos maneras:
Redes administradas, donde se establece conectividad directa entre el cliente y el host de la sesión cuando se utiliza una conexión privada, como Azure ExpressRoute o una red privada virtual (VPN) de sitio a sitio. Una conexión mediante una red administrada se establece de una de las siguientes maneras:
Una conexión UDP directa entre el dispositivo cliente y el host de sesión, donde debe habilitar el agente de escucha de RDP Shortpath y permitir que un puerto de entrada en cada host de sesión acepte las conexiones.
Una conexión UDP directa entre el dispositivo cliente y el host de la sesión, mediante el protocolo Simple Traversal Underneath NAT (STUN) entre un cliente y el host de la sesión. No es necesario que se permitan los puertos de entrada en el host de sesión.
Redes públicas, donde se establece conectividad directa entre el cliente y el host de la sesión cuando se utiliza una conexión pública. Hay dos tipos de conexión cuando se usa una conexión pública, que se enumeran aquí en orden de preferencia:
Una conexión UDP directa mediante el protocolo simple Traversal Underneath NAT (STUN) entre un cliente y el host de sesión.
Una conexión UDP retransmitida mediante el protocolo NAT de retransmisión (TURN) entre un cliente y el host de sesión.
El transporte usado para RDP Shortpath se basa en el Protocolo de control de velocidad universal (URCP). URCP mejora UDP con monitoreo activo de las condiciones de la red y proporciona una utilización justa y completa del enlace. El URCP funciona con niveles bajos de retraso y pérdida según sea necesario.
Importante
-
Nube de Azure: RDP Shortpath para redes públicas a través de STUN y TURN está disponible con carácter general.
-
Nube de Azure para la Administración Pública: RDP Shortpath a través de STUN y TURN está disponible en versión preliminar pública con **servidores dedicados con intervalo IP**20.140.236.0/22. Los clientes pueden probar la característica para el host de sesión en el anillo de validación.
Ventajas principales
El uso de RDP Shortpath tiene las siguientes ventajas clave:
El uso de URCP para mejorar UDP logra el mejor rendimiento al aprender dinámicamente los parámetros de la red y proporcionar al protocolo un mecanismo de control de velocidad.
Mayor rendimiento.
Al usar STUN, la eliminación de puntos de relé adicionales reduce el tiempo de ida y vuelta, mejora la confiabilidad de la conexión y la experiencia del usuario con aplicaciones y métodos de entrada sensibles a la latencia.
Además, para las redes administradas:
RDP Shortpath ofrece soporte técnico para configurar la prioridad de calidad de servicio (QoS) para conexiones RDP a través de marcas de punto de código de servicios diferenciados (DSCP).
El transporte RDP Shortpath permite limitar el tráfico de red saliente especificando una velocidad de limitación para cada sesión.
Cómo funciona RDP Shortpath
Para saber cómo funciona RDP Shortpath para redes administradas y redes públicas, seleccione cada una de las pestañas siguientes.
Puede lograr la conectividad de línea de visión directa necesaria para usar RDP Shortpath con redes administradas mediante los métodos siguientes.
Tener conectividad directa en la línea de visión significa que el cliente puede conectarse directamente al host de la sesión sin que los firewall lo bloqueen.
Nota:
Si usa otros tipos de VPN para conectarse a Azure, se recomienda usar una VPN basada en UDP. Aunque la mayoría de las soluciones VPN basadas en TCP admiten UDP anidado, agregan sobrecarga heredada del control de congestión de TCP, lo que ralentiza el rendimiento de RDP.
Para usar RDP Shortpath para redes administradas, debe habilitar un agente de escucha UDP en los hosts de sesión. De forma predeterminada, se usa el puerto 3390 , aunque puede usar un puerto diferente.
El siguiente diagrama ofrece información general de alto nivel de las conexiones de red al usar RDP Shortpath para redes administradas y hosts de sesión unidos a un dominio de Active Directory.
Secuencia de conexión
Para todas las conexiones, se establece un transporte de conexión inversa basado en TCP a través de la puerta de enlace de Azure Virtual Desktop. A continuación, el cliente y el host de sesión establecen el transporte RDP inicial y comienzan a intercambiar sus funcionalidades. Estas funcionalidades se negocian mediante el siguiente proceso:
El host de sesión envía la lista de sus direcciones IPv4 e IPv6 al cliente.
El cliente inicia el subproceso en segundo plano para establecer un transporte paralelo basado en UDP directamente a una de las direcciones IP del host de sesión.
Mientras el cliente sondea las direcciones IP proporcionadas, continúa estableciendo la conexión inicial a través del transporte de conexión inversa para asegurarse de que no haya retrasos en la conexión del usuario.
Si el cliente tiene una conexión directa con el host de la sesión, establece una conexión segura mediante TLS a través de UDP confiable.
Después de establecer el transporte RDP Shortpath, todos los canales virtuales dinámicos (DVC), incluidos los gráficos remotos, la entrada y el redireccionamiento de dispositivos, se mueven al nuevo transporte. Sin embargo, si un firewall o una topología de red impiden que el cliente establezca conectividad UDP directa, RDP continúa con un transporte de conexión inversa.
Si los usuarios tienen a su disposición RDP Shortpath para redes administradas y redes públicas, se usará el primer algoritmo. El usuario usará la conexión que se establezca primero para esa sesión.
Para proporcionar la mejor oportunidad de que una conexión UDP sea correcta al usar una conexión pública, existen los tipos de conexión directa y de retransmisión :
Conexión directa: STUN se usa para establecer una conexión UDP directa entre un cliente y el host de sesión. Para establecer esta conexión, el cliente y el host de sesión deben poder conectarse entre sí a través de una dirección IP pública y un puerto negociado. Sin embargo, la mayoría de los clientes no conocen su propia dirección IP pública, ya que se encuentran detrás de un dispositivo de puerta de enlace de Traducción de Direcciones de Red (NAT). STUN es un protocolo para la detección automática de una dirección IP pública detrás de un dispositivo de puerta de enlace NAT y el cliente para determinar su propia dirección IP pública.
Para que un cliente use STUN, su red debe permitir el tráfico UDP. Suponiendo que tanto el cliente como el host de sesión puedan enrutar directamente a la dirección IP y puerto detectados del otro, la comunicación se establece con UDP directo a través del protocolo WebSocket. Si los firewalls u otros dispositivos de red bloquean las conexiones directas, se intenta una conexión UDP de retransmisión.
Conexión retransmitida: TURN se usa para establecer una conexión, retransmitiendo tráfico a través de un servidor intermedio entre un cliente y el host de sesión cuando no es posible una conexión directa. TURN es una extensión de STUN. El uso de TURN significa que la dirección IP pública y el puerto se conocen de antemano, lo que se puede permitir a través de firewalls y otros dispositivos de red.
Si los firewalls u otros dispositivos de red bloquean el tráfico UDP, la conexión volverá a un transporte de conexión inversa basado en TCP.
Cuando se establece una conexión, el Establecimiento de Conectividad Interactiva (ICE) coordina la gestión de STUN y TURN para optimizar la probabilidad de que se establezca una conexión y garantizar que se dé prioridad a los protocolos de comunicación de red preferidos.
Cada sesión RDP usa un puerto UDP asignado dinámicamente desde un intervalo de puertos efímero (de 49152 a 65535 de forma predeterminada) que acepta el tráfico de RDP Shortpath. El puerto 65330 se omite de este intervalo, ya que está reservado para uso interno por parte de Azure. También puede usar un intervalo de puertos más pequeño y predecible. Para obtener más información, consulte Limitar el intervalo de puertos que usan los clientes para las redes públicas.
Sugerencia
RDP Shortpath para redes públicas funcionará automáticamente sin ninguna configuración adicional, siempre que las redes y los firewalls permitan el tráfico a través de y la configuración de transporte RDP en el sistema operativo Windows para hosts de sesión y clientes utilice sus valores predeterminados.
El diagrama siguiente ofrece una descripción general de alto nivel de las conexiones de red al usar RDP Shortpath para redes públicas donde los hosts de sesión se unen a Microsoft Entra ID.
Disponibilidad de relés TURN
La retransmisión TURN está disponible en las siguientes regiones de Azure con la retransmisión TURN de ACS (51.5.0.0/16):
- Centro de Australia
- Este de Australia
- Sureste de Australia
- Sur de Brasil
- Centro de Canadá
- Este de Canadá
- Centro de India
- Centro de EE. UU.
- Este de EE. UU.
- Este de EE. UU. 2
- Centro de Francia
- Alemania Central Occidental
- Centro de Israel
- Este de Japón
- Oeste de Japón
- Centro de Corea
- Corea del Sur
- Centro de México
- Centro y norte de EE. UU.
- Norte de Europa
- Oeste de Noruega
- Norte de Sudáfrica
- Oeste de Sudáfrica
- Centro y Sur de EE. UU.
- Sudeste de Asia
- Sur de la India
- Centro de España
- Norte de Suiza
- Norte de Tawain
- Noreste de Tawain
- Centro de Emiratos Árabes Unidos
- Norte de Emiratos Árabes Unidos
- Sur de Reino Unido
- Oeste de Reino Unido
- Centro oeste de EE. UU.
- Oeste de Europa
- Oeste de EE. UU.
- Oeste de EE. UU. 2
- West US 3
Se selecciona un relé TURN en función de la ubicación física del dispositivo cliente. Por ejemplo, si un dispositivo cliente se encuentra en el Reino Unido, se selecciona la retransmisión TURN en la región Sur de Reino Unido u Oeste de Reino Unido. Si un dispositivo cliente está lejos de una retransmisión TURN, es posible que la conexión UDP vuelva a TCP.
Traducción de direcciones de red y firewalls
La mayoría de los clientes de Azure Virtual Desktop se ejecutan en equipos de la red privada. El acceso a Internet se proporciona a través de un dispositivo de puerta de enlace de Traducción de Direcciones de Red (NAT). Por lo tanto, la puerta de enlace NAT modifica todas las solicitudes de red de la red privada y destinadas a Internet. Dicha modificación pretende compartir una única dirección IP pública en todos los equipos de la red privada.
Debido a la modificación del paquete IP, el destinatario del tráfico verá la dirección IP pública de la puerta de enlace NAT en lugar del remitente real. Cuando el tráfico vuelva a la puerta de enlace NAT, se encargará de reenviarlo al destinatario previsto sin el conocimiento del remitente. En la mayoría de los casos, los dispositivos ocultos detrás de una NAT de este tipo no son conscientes de que se está realizando la traducción y no conocen la dirección de red de la puerta de enlace NAT.
NAT es aplicable a las redes virtuales de Azure donde residen todos los hosts de sesión. Cuando un host de sesión intenta llegar a la dirección de red en Internet, la NAT Gateway (ya sea la suya o la predeterminada proporcionada por Azure) o Azure Load Balancer realiza la traducción de direcciones. Para obtener más información acerca de los distintos tipos de traducción de direcciones de red de origen, consulte Usar traducción de direcciones de red de origen (SNAT) para conexiones salientes.
La mayoría de las redes suelen incluir firewalls que inspeccionan el tráfico y lo bloquean en función de las reglas. La mayoría de los clientes configuran sus firewalls para impedir conexiones entrantes (es decir, paquetes no solicitados de Internet enviados sin una solicitud). Los firewalls emplean diferentes técnicas para rastrear el flujo de datos para distinguir entre tráfico solicitado y no solicitado. En el contexto de TCP, el firewall rastrea los paquetes SYN y ACK, y el proceso es sencillo. Los firewalls UDP suelen usar heurística basada en direcciones de paquete para asociar el tráfico con los flujos UDP y permitirlo o bloquearlo. Hay muchas implementaciones de NAT diferentes disponibles.
Secuencia de conexión
Para todas las conexiones, se establece un transporte de conexión inversa basado en TCP a través de la puerta de enlace de Azure Virtual Desktop. A continuación, el cliente y el host de sesión establecen el transporte RDP inicial y comienzan a intercambiar sus funcionalidades. Si RDP Shortpath para redes públicas está habilitado en el host de la sesión, este inicia un proceso denominado recopilación de candidatos:
El host de sesión enumera todas las interfaces de red asignadas a un host de sesión, incluidas las interfaces virtuales, como VPN y Teredo.
Los Servicios de escritorio remoto (TermService) del servicio de Windows asignan sockets UDP en cada interfaz y almacenan el par IP:Port en la tabla de candidatos como un candidato local.
El servicio Servicios de Escritorio remoto usa cada socket UDP asignado en el paso anterior para intentar llegar al servidor STUN de Azure Virtual Desktop en la red pública de Internet. La comunicación se realiza mediante el envío de un pequeño paquete UDP al puerto 3478.
Si el paquete llega al servidor STUN, este responde con la IP y el puerto públicos. Esta información se almacena en la tabla de candidatos como un candidato reflexivo.
Después de que el host de la sesión reúna a todos los candidatos, el host de la sesión utiliza el transporte de conexión inversa establecido para pasar la lista de candidatos al cliente.
Cuando el cliente recibe la lista de candidatos del host de la sesión, el cliente también realiza la recopilación de candidatos por su parte. A continuación, el cliente envía su lista de candidatos al host de la sesión.
Después de que el anfitrión y el cliente de la sesión intercambien sus listas de candidatos, ambas partes intentan conectarse entre sí utilizando todos los candidatos reunidos. Este intento de conexión es simultáneo en ambos lados. Muchas puertas de enlace NAT están configuradas para permitir el tráfico entrante al socket tan pronto como la transferencia de datos salientes lo inicializa. Este comportamiento de las puertas de enlace NAT es la razón por la que la conexión simultánea es esencial. Si se produce un error en STUN porque está bloqueado, se realiza un intento de conexión de retransmisión mediante TURN.
Después del intercambio inicial de paquetes, el cliente y el host de sesión pueden establecer uno o varios flujos de datos. A partir de estos flujos de datos, RDP elige la ruta de red más rápida. A continuación, el cliente establece una conexión segura mediante TLS a través de UDP confiable con el host de la sesión e inicia el transporte RDP Shortpath.
Después de que RDP establezca el transporte RDP Shortpath, todos los canales virtuales dinámicos (DVC), incluidos los gráficos remotos, la entrada y la redirección de dispositivos, se mueven al nuevo transporte.
Si los usuarios tienen a su disposición tanto RDP Shortpath para redes administradas como redes públicas, se usará el algoritmo primero encontrado, lo que significa que el usuario usará la conexión que se establezca primero para esa sesión. Para obtener más información, vea el escenario de ejemplo 4.
Configuración de red
Para admitir RDP Shortpath para redes públicas, normalmente no se necesita ninguna configuración específica. El host de la sesión y el cliente detectarán automáticamente el flujo de datos directo si es posible en la configuración de la red. Sin embargo, cada entorno es único y algunas configuraciones de red pueden afectar negativamente a la tasa de éxito de la conexión directa. Siga las recomendaciones para aumentar la probabilidad de un flujo directo de datos.
Como RDP Shortpath usa UDP para establecer un flujo de datos, si un firewall de la red bloquea el tráfico UDP, se producirá un error en RDP Shortpath y la conexión volverá al transporte de conexión inversa basado en TCP. Azure Virtual Desktop utiliza servidores STUN proporcionados por Azure Communication Services y Microsoft Teams. Por la naturaleza de la característica, se requiere conectividad saliente entre los hosts de sesión y el cliente. Desafortunadamente, no puede predecir dónde se encuentran sus usuarios en la mayoría de los casos. Por lo tanto, se recomienda permitir la conectividad UDP saliente de los hosts de sesión a Internet. Para reducir el número de puertos necesarios, puede limitar el intervalo de puertos que usan los clientes para el flujo UDP. Use las siguientes tablas como referencia al configurar firewalls para RDP Shortpath.
Si su entorno utiliza NAT simétrica, que es la asignación de una única IP:Port de origen privado a una única IP:Port de destino público, puede utilizar una conexión de retransmisión con TURN. Este será el caso si usa Azure Firewall y Azure NAT Gateway. Para más información sobre NAT con redes virtuales de Azure, consulte Traducción de direcciones de red de origen con redes virtuales.
Tenemos algunas recomendaciones generales para conexiones correctas mediante RDP Shortpath para redes públicas. Para obtener más información, vea Recomendaciones generales.
Cuando los usuarios tienen disponible RDP Shortpath para la red administrada y las redes públicas, se usará el primer algoritmo encontrado. El usuario usará la conexión que se establezca primero para esa sesión. Para obtener más información, vea Escenarios de ejemplo.
Las secciones siguientes contienen los requisitos de origen, destino y protocolo para los hosts de sesión y los dispositivos cliente que deben permitirse para que RDP Shortpath funcione.
Nota:
Microsoft ha completado la transición de la subred 20.202.0.0/16 compartida anteriormente al nuevo intervalo IP de retransmisión TURN 51.5.0.0/16 en 39 regiones de Azure. Esta nueva gama está dedicada exclusivamente a Azure Virtual Desktop y Windows 365, separándola de la infraestructura de Azure Communication Services. La actualización está diseñada para mejorar RDP Shortpath para redes públicas (a través de TURN/Relay), lo que ofrece una conectividad más rápida y confiable y una experiencia de usuario mejorada.
Nota:
Las conexiones basadas en TURN son susceptibles a caídas de conexión durante las actualizaciones de retransmisión TURN. Estas actualizaciones suelen producirse durante ventanas de mantenimiento planeado, pero en ocasiones pueden producirse fuera de la ventana planeada debido a correcciones urgentes de la infraestructura de Azure.
En todos los escenarios anteriores, el cliente se vuelve a conectar automáticamente en unos segundos.
Red virtual del host de sesión
En la tabla siguiente se detallan los requisitos de origen, destino y protocolo de RDP Shortpath para la red virtual del host de sesión.
| Nombre |
Origen |
Puerto de origen |
Destino |
Puerto de destino |
Protocolo |
Acción |
| ATURDIR conexión directa |
Subred de VM |
Cualquiera |
Cualquiera |
1024-65535
(predeterminado 49152-65535) |
UDP |
Permitir |
| Relé STUN/TURN |
Subred de VM |
Cualquiera |
51.5.0.0/16 |
3478 |
UDP |
Permitir |
Red de cliente
En la tabla siguiente se detallan los requisitos de origen, destino y protocolo para los dispositivos cliente.
| Nombre |
Origen |
Puerto de origen |
Destino |
Puerto de destino |
Protocolo |
Acción |
| ATURDIR conexión directa |
Red de cliente |
Cualquiera |
Direcciones IP públicas asignadas a NAT Gateway o Azure Firewall (proporcionadas por el punto de conexión STUN) |
1024-65535
(predeterminado 49152-65535) |
UDP |
Permitir |
| Relé STUN/TURN |
Red de cliente |
Cualquiera |
51.5.0.0/16 |
3478 |
UDP |
Permitir |
Importante
El intervalo IP de retransmisión TURN dedicado para Azure Government es 20.140.236.0/22. RDP Shortpath vía TURN se encuentra actualmente en versión preliminar pública en Azure Government. Los clientes pueden probar la característica mediante el anillo de validación.
Red virtual del host de sesión
En la tabla siguiente se detallan los requisitos de origen, destino y protocolo de RDP Shortpath para la red virtual del host de sesión.
| Nombre |
Origen |
Puerto de origen |
Destino |
Puerto de destino |
Protocolo |
Acción |
| ATURDIR conexión directa |
Subred de VM |
Cualquiera |
Cualquiera |
1024-65535
(predeterminado: 49152-65535) |
UDP |
Permitir |
| Relé STUN/TURN |
Subred de VM |
Cualquiera |
20.140.236.0/22 |
3478 |
UDP |
Permitir |
Red de cliente
En la tabla siguiente se detallan los requisitos de origen, destino y protocolo para los dispositivos cliente.
| Nombre |
Origen |
Puerto de origen |
Destino |
Puerto de destino |
Protocolo |
Acción |
| ATURDIR conexión directa |
Red de cliente |
Cualquiera |
Direcciones IP públicas asignadas a NAT Gateway o Azure Firewall (proporcionadas por el punto de conexión STUN) |
1024-65535
(predeterminado: 49152-65535) |
UDP |
Permitir |
| Relé STUN/TURN |
Red de cliente |
Cualquiera |
20.140.236.0/22 |
3478 |
UDP |
Permitir |
Soporte técnico de Teredo
Aunque no es necesario para RDP Shortpath, Teredo agrega candidatos de recorrido NAT adicionales y aumenta la posibilidad de una conexión correcta de RDP Shortpath en redes solo IPv4. Para obtener información sobre cómo habilitar Teredo en hosts y clientes de sesión, consulta Habilitar la compatibilidad con Teredo.
Compatibilidad con UPnP
Para mejorar las posibilidades de una conexión directa, en el lado del cliente de Escritorio remoto, RDP Shortpath puede usar UPnP para configurar una asignación de puertos en el enrutador NAT. UPnP es una tecnología estándar usada por varias aplicaciones, como Xbox, Optimización de distribución y Teredo. UPnP suele estar disponible en enrutadores que suelen encontrarse en una red doméstica. UPnP está habilitado de forma predeterminada en la mayoría de los enrutadores domésticos y puntos de acceso, pero suele estar deshabilitado en las redes corporativas.
Recomendaciones generales
Estas son algunas recomendaciones generales al usar RDP Shortpath para redes públicas:
Evite usar configuraciones de túnel forzado si los usuarios acceden a Azure Virtual Desktop a través de Internet.
Asegúrese de que no está usando configuraciones de NAT doble o NAT de grado de operador (CGN).
Recomiende a los usuarios que no deshabiliten UPnP en sus enrutadores domésticos.
Evite el uso de servicios de inspección de paquetes en la nube.
Evita usar soluciones VPN basadas en TCP.
Habilitar la conectividad IPv6 o Teredo.
Seguridad de la conexión
RDP Shortpath amplía las capacidades de multitransporte de RDP. No reemplaza el transporte de conexión inversa, sino que lo complementa. La intermediación de sesión inicial se administra a través del servicio de Escritorio virtual de Azure y el transporte de conexión inversa. Se omiten todos los intentos de conexión a menos que coincidan primero con la sesión de conexión inversa. RDP Shortpath se establece después de la autenticación y, si se establece correctamente, se descarta el transporte de conexión inversa y todo el tráfico fluye a través de RDP Shortpath.
RDP Shortpath usa una conexión segura mediante TLS a través de UDP confiable entre el cliente y el host de sesión mediante los certificados del host de sesión. De forma predeterminada, el sistema operativo genera de forma automática el certificado usado para el cifrado RDP durante la implementación. Azure Virtual Desktop no admite el uso de un certificado emitido por una entidad de certificación en este momento.
Escenarios de ejemplo
Estos son algunos escenarios de ejemplo para mostrar cómo se evalúan las conexiones para decidir si RDP Shortpath se usa en diferentes topologías de red.
Escenario 1
Solo se puede establecer una conexión UDP entre el dispositivo cliente y el host de sesión a través de una red pública (Internet). No hay disponible una conexión directa, como una VPN. UDP se permite a través del firewall o el dispositivo NAT.
Escenario 2
Un firewall o dispositivo NAT bloquea una conexión UDP directa, pero una conexión UDP retransmitida se puede retransmitir mediante TURN entre el dispositivo cliente y el host de sesión a través de una red pública (Internet). No hay otra conexión directa, como una VPN, disponible.
Escenario 3
Se puede establecer una conexión UDP entre el dispositivo cliente y el host de sesión a través de una red pública o una conexión VPN directa, pero RDP Shortpath para redes administradas no está habilitado. Cuando el cliente inicia la conexión, el protocolo ICE/STUN puede ver varias rutas y evaluará cada ruta y elegirá la que tenga la latencia más baja.
En este ejemplo, se realizará una conexión UDP mediante RDP Shortpath para redes públicas a través de la conexión VPN directa, ya que tiene la latencia más baja, como se muestra en la línea verde.
Escenario 4
Tanto RDP Shortpath para redes públicas como redes administradas están habilitados. Se puede establecer una conexión UDP entre el dispositivo cliente y el host de sesión a través de una red pública o una conexión VPN directa. Cuando el cliente inicia la conexión, hay intentos simultáneos de conectarse mediante RDP Shortpath para redes administradas a través del puerto 3390 (de forma predeterminada) y RDP Shortpath para redes públicas a través del protocolo ICE/STUN. Se usará el primer algoritmo encontrado y el usuario usará la conexión que se establezca primero para esa sesión.
Dado que pasar por una red pública tiene más pasos, por ejemplo, un dispositivo NAT, un equilibrador de carga o un servidor STUN, es probable que el primer algoritmo encontrado seleccione la conexión mediante RDP Shortpath para las redes administradas y se establezca primero.
Escenario 5
Se puede establecer una conexión UDP entre el dispositivo cliente y el host de sesión a través de una red pública o una conexión VPN directa, pero RDP Shortpath para redes administradas no está habilitado. Para evitar que ICE/STUN use una ruta determinada, un administrador puede bloquear una de las rutas para el tráfico UDP. Bloquear una ruta garantizaría que siempre se use la ruta restante.
En este ejemplo, UDP está bloqueado en la conexión VPN directa y el protocolo ICE/STUN establece una conexión a través de la red pública.
Escenario 6
Tanto RDP Shortpath para redes públicas como redes administradas están configuradas; sin embargo, no se pudo establecer una conexión UDP mediante una conexión VPN directa. Un firewall o dispositivo NAT también bloquea una conexión UDP directa mediante la red pública (Internet), pero una conexión UDP retransmitida se puede retransmitir mediante TURN entre el dispositivo cliente y el host de sesión a través de una red pública (Internet).
Escenario 7
Tanto RDP Shortpath para redes públicas como redes administradas están configurados; sin embargo, no se pudo establecer una conexión UDP. En este caso, se producirá un error en RDP Shortpath y la conexión volverá al transporte de conexión inversa basado en TCP.
Pasos siguientes
