Problemen met RDP-shortpath voor openbare netwerken oplossen

Belangrijk

Het gebruik van RDP Shortpath voor openbare netwerken met TURN voor Azure Virtual Desktop is momenteel beschikbaar als PREVIEW-versie. Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.

Als u problemen ondervindt bij het gebruik van RDP-shortpath voor openbare netwerken, gebruikt u de informatie in dit artikel om problemen op te lossen.

STUN/TURN-serverconnectiviteit en NAT-type controleren

U kunt de connectiviteit met de STUN/TURN-eindpunten valideren en controleren of de basisfunctionaliteit van UDP werkt door het uitvoerbare bestand avdnettest.exeuit te voeren. Hier volgt een downloadkoppeling naar de nieuwste versie van avdnettest.exe.

U kunt uitvoeren avdnettest.exe door te dubbelklikken op het bestand of door het uit te voeren vanaf de opdrachtregel. De uitvoer ziet er ongeveer als volgt uit als de verbinding tot stand is gebracht:

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.

Belangrijk

Tijdens de preview is TURN alleen beschikbaar voor verbindingen met sessiehosts in een validatiehostgroep. Zie Uw hostgroep definiëren als een validatieomgeving om uw hostgroep te configureren als een validatieomgeving.

Foutgegevens vastgelegd in Log Analytics

Hier volgen enkele fouttitels die mogelijk zijn vastgelegd in Log Analytics en wat ze betekenen.

ShortpathTransportNetworkDrop

Voor TCP onderscheiden we twee verschillende paden: de sessiehost naar de gateway en de gateway naar client, maar dat is niet logisch voor UDP omdat er geen gateway is. Het andere onderscheid voor TCP is dat in veel gevallen een van de eindpunten, of misschien een infrastructuur in het midden, een TCP Reset-pakket (RST-besturingsbit) genereert, waardoor de TCP-verbinding hard wordt afgesloten. Dit werkt omdat TCP RST (en ook TCP FIN voor een probleemloos afsluiten) wordt verwerkt door het besturingssysteem en ook door sommige routers, maar niet door de toepassing. Dit betekent dat als een toepassing vastloopt, Windows de peer op de hoogte stelt dat de TCP-verbinding is verdwenen, maar dat er geen dergelijk mechanisme bestaat voor UDP.

De meeste verbindingsfouten, zoals ConnectionFailedClientDisconnect en ConnectionFailedServerDisconnect, worden veroorzaakt door TCP Reset-pakketten, geen time-out. Er is geen manier voor het besturingssysteem of een router om iets te signaleren met UDP, dus de enige manier om te weten dat de peer is verdwenen, is door een time-outbericht.

ShortpathTransportReliabilityThresholdFailure

Deze fout wordt geactiveerd als een specifiek pakket niet doorkomt, ook al is de verbinding niet verbroken. Het pakket wordt maximaal 50 keer opnieuw verzonden, dus dit is onwaarschijnlijk, maar kan gebeuren in de volgende scenario's:

  1. De verbinding was erg snel en stabiel voordat deze plotseling niet meer werkte. De time-out die is vereist totdat een pakket verloren is aangegeven, is afhankelijk van de retourtijd (RTT) tussen de client en de sessiehost. Als de RTT erg laag is, kan één kant proberen om een pakket zeer vaak opnieuw te verzenden, zodat de tijd die nodig is om 50 pogingen te bereiken, minder kan zijn dan de gebruikelijke time-outwaarde van 17 seconden.

  2. Het pakket is erg groot. De maximale pakketgrootte die kan worden verzonden, is beperkt. De grootte van het pakket wordt getest, maar het kan fluctueren en soms kleiner worden. Als dat gebeurt, is het mogelijk dat het verzonden pakket te groot is en consistent mislukt.

ConnectionBrokenMissedHeartbeatThresholdExceeded

Dit is een time-out op RDP-niveau. Vanwege een onjuiste configuratie werd de time-out op RDP-niveau soms geactiveerd vóór de time-out op UDP-niveau.