Aktivieren von RDP Shortpath für öffentliche Netzwerke
Wenn Sie Probleme beim Verwenden von RDP Shortpath für öffentliche Netzwerke haben, verwenden Sie die Informationen in diesem Artikel, um die Problembehandlung zu unterstützen.
Überprüfen der STUN/TURN-Serverkonnektivität und des NAT-Typs
Sie können die Konnektivität mit den STUN/TURN-Endpunkten überprüfen und bestätigen, dass die grundlegende UDP-Funktionalität funktioniert, indem Sie das PowerShell-Skript 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 sie über die Befehlszeile ausführen. Die Ausgabe sieht ähnlich wie dieses Beispiel aus, wenn die Konnektivität erfolgreich ist:
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.
In Log Analytics protokollierte Fehlerinformationen
Hier sind einige Fehlertitel aufgeführt, die möglicherweise in Log Analytics protokolliert sind und ihre Bedeutung.
ShortpathTransportNetworkDrop
Bei TCP unterscheiden wir zwei verschiedene Pfade – den Sitzungshost zum Gateway und das Gateway zum Client – aber das ist für UDP nicht sinnvoll, da kein Gateway vorhanden 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. Das bedeutet, dass Windows beim Absturz einer Anwendung den Peer benachrichtigt, dass die TCP-Verbindung nicht mehr besteht, während es für UDP keinen solchen Mechanismus gibt.
Die meisten Verbindungsfehler, z. B. ConnectionFailedClientDisconnect und ConnectionFailedServerDisconnect, werden durch TCP-Zurücksetzungspakete und nicht durch ein Timeout verursacht. Es gibt keine Möglichkeit für das Betriebssystem oder einen Router, irgendetwas mit UDP zu signalisieren, daher ist die einzige Möglichkeit, zu wissen, dass der Peer weg ist, eine Timeout-Meldung.
ShortpathTransportReliabilityThresholdFailure
Dieser Fehler wird ausgelöst, wenn ein bestimmtes Paket nicht durchkommt, obwohl die Verbindung steht. Das Paket wird bis zu 50 Mal erneut gesendet, daher ist dieser Fehler unwahrscheinlich, kann aber in den folgenden Szenarien auftreten:
Die Verbindung war sehr schnell und stabil, bevor sie plötzlich nicht mehr funktionierte. Das erforderliche Timeout, bis ein Paket für verloren erklärt wird, hängt von der Paketumlaufzeit (RTT) zwischen dem Client und dem Sitzungshost ab. Wenn die RTT sehr niedrig ist, kann eine Seite versuchen, ein Paket sehr häufig erneut zu senden, sodass die Zeit, die benötigt wird, um 50 Versuche zu erreichen, kleiner als der übliche Timeoutwert von 17 Sekunden sein kann.
Das Paket ist sehr 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 Fehlkonfiguration wird das Timeout auf RDP-Ebene manchmal vor dem Timeout auf UDP-Ebene ausgelöst.