Aktivieren von RDP Shortpath für öffentliche Netzwerke

Artikel
01/22/2025

Dieser Artikel hilft bei der Behandlung von Problemen bei der Verwendung des Remotedesktopprotokolls (RDP) Shortpath für öffentliche Netzwerke.

Überprüfen des STUN-, TURN-Serverkonnektivitäts- und NAT-Typs

Sie können die Konnektivität mit den STUN- und TURN-Endpunkten überprüfen und überprüfen, ob die grundlegende Udp-Funktionalität (User Datagram Protocol) funktioniert, indem Sie die ausführbare avdnettest.exe ausführen. Hier ist ein Downloadlink zur neuesten Version von avdnettest.exe.

Sie können avdnettest.exe ausführen, indem Sie auf die Datei doppelklicken oder über die Befehlszeile ausführen. Die Ausgabe sieht ähnlich aus, wenn die Verbindung erfolgreich ist:

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.

In Log Analytics protokollierte Fehlerinformationen

Hier sind einige Fehlertitel, die sie möglicherweise in Log Analytics protokolliert haben und was sie bedeuten.

ShortpathTransportNetworkDrop

Für TCP-Verbindungen (Transmission Control Protocol) gibt es zwei verschiedene Pfade:

Vom Sitzungshost zum Gateway
Vom Gateway zum Client

Für UDP-Verbindungen gilt dieser Unterschied jedoch nicht, da kein Gateway beteiligt ist. Der andere Unterschied für TCP besteht darin, dass in vielen Fällen einer der Endpunkte oder vielleicht eine Infrastruktur in der Mitte ein TCP-Zurücksetzungspaket (RST-Steuerbit) generiert, was zu einem harten Herunterfahren der TCP-Verbindung führt. Dies funktioniert, da TCP RST (und auch TCP FIN für das ordnungsgemäße Herunterfahren) vom Betriebssystem und auch von einigen Routern, aber nicht von der Anwendung verarbeitet wird. Dies bedeutet, dass Windows, wenn eine Anwendung abstürzt, den Peer benachrichtigt, dass die TCP-Verbindung nicht mehr vorhanden ist, aber kein solcher Mechanismus für UDP vorhanden ist.

Die meisten Verbindungsfehler, z . B. ConnectionFailedClientDisconnect und ConnectionFailedServerDisconnect, werden durch TCP-Zurücksetzungspakete verursacht, kein Timeout. Es gibt keine Möglichkeit für das Betriebssystem oder einen Router, etwas mit UDP zu signalisieren, daher ist die einzige Möglichkeit, den Peer zu kennen, eine Timeoutnachricht.

ShortpathTransportReliabilityThresholdFailure

Dieser Fehler wird ausgelöst, wenn ein bestimmtes Paket nicht durchkommt, obwohl die Verbindung nicht tot ist. Das Paket wird bis zu 50 Mal erneut gesendet, daher ist dieser Fehler unwahrscheinlich, kann aber in den folgenden Szenarien auftreten:

Die Verbindung ist schnell und stabil, bevor sie plötzlich nicht mehr funktioniert. Das Timeout, das erforderlich ist, bis ein Paket verloren geht, hängt von der Roundtripzeit (Roundtrip Time, RTT) zwischen dem Client und dem Sitzungshost ab. Wenn das RTT niedrig ist, kann eine Seite versuchen, ein Paket häufig erneut zu senden, sodass die Zeit, die es dauert, 50 Versuche zu erreichen, kleiner als der übliche Timeoutwert von 17 Sekunden sein kann.
Das Paket ist groß. Die maximale Paketgröße, die übertragen werden kann, ist begrenzt. Die Größe des Pakets wird untersucht, kann jedoch schwanken und manchmal schrumpfen. In diesem Fall ist es möglich, dass das gesendete Paket zu groß ist und immer wieder fehlschlägt.

ConnectionBrokenMissedHeartbeatThresholdExceeded

Dies ist ein TIMEOUT auf RDP-Ebene. Aufgrund einer fehlkonfigurierten Konfiguration würde das Timeout auf RDP-Ebene manchmal vor dem Timeout auf UDP-Ebene ausgelöst.

Freigeben über