Comparteix a través de

Solución de problemas con RDP Shortpath para las redes públicas

  • Article

Importante

El uso de RDP Shortpath para redes públicas con TURN para Azure Virtual Desktop se encuentra actualmente en versión preliminar. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

Si tiene problemas al usar RDP Shortpath para redes públicas, la información de este artículo le ayudará.

Comprobación de la conectividad del servidor STUN/TURN y el tipo NAT

Puede validar la conectividad a los puntos de conexión de STUN/TURN y comprobar que la funcionalidad básica de UDP funciona mediante la ejecución archivo ejecutable avdnettest.exe. Este es un vínculo de descarga a la versión más reciente de avdnettest.exe.

Para ejecutar avdnettest.exe, haga doble clic en el archivo o ejecútelo desde la línea de comandos. La salida tendrá un aspecto similar a esta si la conectividad es correcta:

Checking DNS service ... OK
Checking TURN support ... OK
Checking ACS server 20.202.68.109:3478 ... OK
Checking ACS server 20.202.21.66:3478 ... OK

You have access to TURN servers and your NAT type appears to be 'cone shaped'.
Shortpath for public networks is very likely to work on this host.

Importante

Durante la versión preliminar, TURN solo está disponible para las conexiones a los hosts de sesión de un grupo de hosts de validación. Para configurar el grupo de hosts como entorno de validación, consulte Definición del grupo de hosts como entorno de validación.

Información de error registrada en Log Analytics

Estos son algunos títulos de error que puede ver registrados en Log Analytics y qué significan.

ShortpathTransportNetworkDrop

En el caso de TCP, diferenciamos dos rutas de acceso distintas: el host de sesión a la puerta de enlace y la puerta de enlace al cliente, pero eso no tiene sentido para UDP, ya que no hay una puerta de enlace. La otra distinción para TCP es que, en muchos casos, uno de los puntos de conexión, o quizás alguna infraestructura en el medio, genera un paquete de restablecimiento TCP (bit de control de RST), lo que provoca un apagado total de la conexión TCP. Esto funciona porque RST de TCP (y también FIN de TCP para apagado correcto) se controla mediante el sistema operativo y también algunos enrutadores, pero no la aplicación. Esto significa que, si una aplicación se bloquea, Windows notificará al nodo del mismo nivel que la conexión TCP ha desaparecido, pero no existe ese mecanismo para UDP.

La mayoría de los errores de conexión, como ConnectionFailedClientDisconnect y ConnectionFailedServerDisconnect, son provocados por paquetes de restablecimiento de TCP, no por un tiempo de espera. No hay forma de que el sistema operativo o un enrutador indiquen nada con UDP, por lo que la única manera de saber que el nodo del mismo nivel ha desaparecido es mediante un mensaje de tiempo de espera.

ShortpathTransportReliabilityThresholdFailure

Este error se desencadena si un paquete específico no pasa, aunque la conexión no esté inactiva. El paquete se vuelve a enviar hasta 50 veces, por lo que es poco probable, pero puede ocurrir en los escenarios siguientes:

  1. La conexión era muy rápida y estable antes de que de repente dejara de funcionar. El tiempo de espera necesario hasta que se declara perdido un paquete, depende del tiempo de ida y vuelta (RTT) entre el cliente y el host de sesión. Si el RTT es muy bajo, un lado puede intentar volver a enviar un paquete con mucha frecuencia, por lo que el tiempo necesario para alcanzar 50 intentos puede ser menor que el valor de tiempo de espera habitual de 17 segundos.

  2. El paquete es muy grande. El tamaño máximo de paquete que se puede transmitir es limitado. El tamaño del paquete se sondea, pero puede fluctuar y, a veces, reducirse. Si esto sucede, es posible que el paquete que se envía sea demasiado grande y se producirá un error de manera sistemática.

ConnectionBrokenMissedHeartbeatThresholdExceeded

Se trata de un tiempo de espera de RDP. Debido a una configuración incorrecta, el tiempo de espera de RDP a veces se desencadenaría antes del tiempo de espera de UDP.