Dela via

Felsöka RDP Shortpath för offentliga nätverk

  • Artikel

Den här artikeln hjälper dig att felsöka problem när du använder RDP-kortsökvägen (Remote Desktop Protocol) för offentliga nätverk.

Verifiera STUN, TURN-serveranslutning och NAT-typ

Du kan verifiera anslutningen till STUN- och TURN-slutpunkterna och kontrollera att grundläggande UDP-funktioner (User Datagram Protocol) fungerar genom att köra den körbara avdnettest.exe. Här är en nedladdningslänk till den senaste versionen av avdnettest.exe.

Du kan köra avdnettest.exe genom att dubbelklicka på filen eller köra den från kommandoraden. Utdata ser ut ungefär så här om anslutningen lyckas:

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.

Felinformation loggad i Log Analytics

Här följer några feltitlar som du kan se loggade i Log Analytics och vad de betyder.

ShortpathTransportNetworkDrop

För TCP-anslutningar (Transmission Control Protocol) finns det två olika sökvägar:

  • Från sessionsvärden till gatewayen
  • Från gatewayen till klienten

Men för UDP-anslutningar är den här skillnaden inte tillämplig eftersom det inte finns någon gateway inblandad. Den andra skillnaden för TCP är att i många fall genererar en av slutpunkterna, eller kanske någon infrastruktur i mitten, ett TCP-återställningspaket (RST-kontrollbit), vilket orsakar en hård avstängning av TCP-anslutningen. Detta fungerar eftersom TCP RST (och även TCP FIN för graciös avstängning) hanteras av operativsystemet och även vissa routrar, men inte programmet. Det innebär att om ett program kraschar meddelar Windows peer att TCP-anslutningen är borta, men det finns ingen sådan mekanism för UDP.

De flesta anslutningsfel, till exempel ConnectionFailedClientDisconnect och ConnectionFailedServerDisconnect, orsakas av TCP-återställningspaket, inte en tidsgräns. Det finns inget sätt för operativsystemet eller en router att signalera något med UDP, så det enda sättet att veta att peer är borta är med ett timeout-meddelande.

ShortpathTransportReliabilityThresholdFailure

Det här felet utlöses om ett specifikt paket inte når fram, även om anslutningen inte är död. Paketet skickas på nytt upp till 50 gånger, så det är osannolikt men kan inträffa i följande scenarier:

  • Anslutningen är snabb och stabil innan den plötsligt slutar fungera. Tidsgränsen som krävs tills ett paket har deklarerats förlorat beror på tidsåtgången (RTT) mellan klienten och sessionsvärden. Om RTT är låg kan en sida försöka skicka om ett paket ofta, så den tid det tar att nå 50 försök kan vara mindre än det vanliga timeout-värdet på 17 sekunder.
  • Paketet är stort. Den maximala paketstorleken som kan överföras är begränsad. Storleken på paketet avsöks, men det kan variera och ibland krympa. Om det händer är det möjligt att paketet som skickas är för stort och konsekvent misslyckas.

ConnectionBrokenMissedHeartbeatThresholdExceeded

Det här är en tidsgräns på RDP-nivå. På grund av felkonfiguration utlöses tidsgränsen på RDP-nivå ibland innan tidsgränsen på UDP-nivå.