Felsöka RDP Shortpath för offentliga nätverk
Om du har problem med att använda RDP Shortpath för offentliga nätverk använder du informationen i den här artikeln för att felsöka.
Verifiera STUN/TURN-serveranslutning och NAT-typ
Du kan verifiera anslutningen till STUN/TURN-slutpunkterna och kontrollera att grundläggande UDP-funktioner 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 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.
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 särskiljer vi två olika sökvägar – sessionsvärden till gatewayen och gatewayen till klienten – men det är inte meningsfullt för UDP eftersom det inte finns någon gateway. 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-datorn om 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 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 var mycket 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 mycket låg kan en sida försöka skicka om ett paket mycket 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 mycket 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 före tidsgränsen på UDP-nivå.