Compartir a través de

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

  • Artículo

Este artículo ayuda a solucionar problemas al usar Shortpath del Protocolo de escritorio remoto (RDP) para redes públicas.

Comprobar STUN, TURN server connectivity and NAT type (Comprobar STUN, TURN server connectivity and NAT type)

Puede validar la conectividad con los puntos de conexión STUN y TURN y comprobar que la funcionalidad básica del Protocolo de datagramas de usuario (UDP) funciona ejecutando el archivo ejecutable avdnettest.exe. Este es un vínculo de descarga a la versión más reciente de avdnettest.exe.

Puede ejecutar avdnettest.exe haciendo doble clic en el archivo o ejecutándolo desde la línea de comandos. La salida es similar a esta si la conectividad se realiza correctamente:

Checking DNS service ... OK
Checking TURN support ... OK
Checking ACS server <IP Address:Port Number> ... OK
Checking ACS server <IP Address:Port Number> ... 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.

Información de error registrada en Log Analytics

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

ShortpathTransportNetworkDrop

Para las conexiones del Protocolo de control de transmisión (TCP), hay dos rutas de acceso diferentes:

  • Desde el host de sesión a la puerta de enlace
  • Desde la puerta de enlace al cliente

Sin embargo, para las conexiones UDP, esta diferencia no es aplicable, ya que no hay ninguna puerta de enlace implicada. 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 notifica al mismo nivel que la conexión TCP ha desaparecido, pero no existe este mecanismo para UDP.

La mayoría de los errores de conexión, como ConnectionFailedClientDisconnect y ConnectionFailedServerDisconnect, se deben a paquetes de restablecimiento tcp, no a 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 sistema del mismo nivel ha desaparecido es mediante un mensaje de tiempo de espera.

ShortpathTransportReliabilityThresholdFailure

Este error se desencadena si un paquete específico no se realiza, 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:

  • La conexión es rápida y estable antes de que de repente deje de funcionar. El tiempo de espera necesario hasta que se declare la pérdida de un paquete depende del tiempo de ida y vuelta (RTT) entre el cliente y el host de sesión. Si el RTT es bajo, un lado puede intentar volver a enviar un paquete con 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.
  • El paquete es 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 nivel RDP. Debido a errores de configuración, el tiempo de espera de nivel rdP se desencadenaría a veces antes del tiempo de espera de nivel UDP.