Udostępnij za pośrednictwem

Rozwiązywanie problemów z protokołem RDP Shortpath dla sieci publicznych

  • Artykuł

Ten artykuł ułatwia rozwiązywanie problemów podczas korzystania z protokołu RDP (Remote Desktop Protocol) Shortpath dla sieci publicznych.

Weryfikowanie łączności serwera STUN, TURN i typu translatora adresów sieciowych

Możesz zweryfikować łączność z punktami końcowymi STUN i TURN oraz sprawdzić, czy podstawowa funkcja protokołu UDP (User Datagram Protocol) działa, uruchamiając plik wykonywalny avdnettest.exe. Oto link pobierania do najnowszej wersji avdnettest.exe.

Możesz uruchomić avdnettest.exe , klikając dwukrotnie plik lub uruchamiając go w wierszu polecenia. Dane wyjściowe wyglądają podobnie do tych, jeśli łączność zakończy się pomyślnie:

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.

Informacje o błędzie zarejestrowane w usłudze Log Analytics

Poniżej przedstawiono niektóre tytuły błędów, które mogą być widoczne w usłudze Log Analytics i co oznaczają.

ShortpathTransportNetworkDrop

W przypadku połączeń protokołu TCP (Transmission Control Protocol) istnieją dwie różne ścieżki:

  • Z hosta sesji do bramy
  • Z bramy do klienta

Jednak w przypadku połączeń UDP ta różnica nie ma zastosowania, ponieważ nie ma żadnej bramy. Innym rozróżnieniem dla protokołu TCP jest to, że w wielu przypadkach jeden z punktów końcowych, a może niektóre infrastruktury w środku, generuje pakiet resetowania TCP (bit kontroli RST), co powoduje twarde zamknięcie połączenia TCP. Działa to, ponieważ protokół TCP RST (a także TCP FIN do bezpiecznego zamykania) jest obsługiwany przez system operacyjny, a także niektóre routery, ale nie aplikację. Oznacza to, że jeśli aplikacja ulegnie awarii, system Windows powiadomi element równorzędny, że połączenie TCP nie zostanie nawiązane, ale nie istnieje taki mechanizm dla protokołu UDP.

Większość błędów połączenia, takich jak ConnectionFailedClientDisconnect i ConnectionFailedServerDisconnect, są spowodowane przez pakiety resetowania TCP, a nie limit czasu. Nie ma możliwości, aby system operacyjny lub router zasygnalizował coś z UDP, więc jedynym sposobem, aby wiedzieć, że element równorzędny zniknął, to komunikat przekroczenia limitu czasu.

ShortpathTransportReliabilityThresholdFailure

Ten błąd jest wyzwalany, jeśli określony pakiet nie przechodzi, mimo że połączenie nie jest martwe. Pakiet jest oburzony do 50 razy, więc jest mało prawdopodobne, ale może wystąpić w następujących scenariuszach:

  • Połączenie jest szybkie i stabilne, zanim nagle przestanie działać. Limit czasu wymagany do momentu zadeklarowania utraty pakietu zależy od czasu rundy (RTT) między klientem a hostem sesji. Jeśli RTT jest niski, jedna strona może spróbować ponownie wysłać pakiet często, więc czas potrzebny do osiągnięcia 50 prób może być mniejszy niż zwykle limit czasu 17 sekund.
  • Pakiet jest duży. Maksymalny rozmiar pakietu, który można przesłać, jest ograniczony. Rozmiar pakietu jest sondowany, ale może się wahać i czasami zmniejszać. W takim przypadku istnieje możliwość, że wysyłany pakiet jest zbyt duży i będzie stale ulegać awarii.

ConnectionBrokenMissedHeartbeatThresholdExceeded

Jest to limit czasu na poziomie protokołu RDP. Ze względu na błędną konfigurację limit czasu na poziomie protokołu RDP czasami jest wyzwalany przed przekroczeniem limitu czasu na poziomie UDP.