Problemen met RDP Shortpath voor openbare netwerken oplossen
Dit artikel helpt bij het oplossen van problemen bij het gebruik van Remote Desktop Protocol (RDP) Shortpath voor openbare netwerken.
STUN, TURN-serverconnectiviteit en NAT-type controleren
U kunt de connectiviteit met de STUN- en TURN-eindpunten valideren en controleren of de basisfunctionaliteit User Datagram Protocol (UDP) werkt door het uitvoerbare avdnettest.exe uit te voeren. Hier volgt een downloadkoppeling naar de nieuwste versie van avdnettest.exe.
U kunt avdnettest.exe uitvoeren 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 is geslaagd:
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.
Foutinformatie die is vastgelegd in Log Analytics
Hier volgen enkele fouttitels die mogelijk zijn vastgelegd in Log Analytics en wat ze betekenen.
ShortpathTransportNetworkDrop
Voor TCP-verbindingen (Transmission Control Protocol) zijn er twee verschillende paden:
- Van de sessiehost naar de gateway
- Van de gateway naar de client
Voor UDP-verbindingen is dit verschil echter niet van toepassing, omdat er geen gateway betrokken 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 correct afsluiten) wordt verwerkt door het besturingssysteem en ook sommige routers, maar niet de toepassing. Dit betekent dat als een toepassing vastloopt, Windows de peer meldt dat de TCP-verbinding is verdwenen, maar 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 weg is, is door een time-outbericht.
ShortpathTransportReliabilityThresholdFailure
Deze fout wordt geactiveerd als een specifiek pakket niet doorkomt, ook al is de verbinding niet dood. Het pakket wordt maximaal 50 keer opnieuw verzonden, dus het is onwaarschijnlijk, maar kan zich in de volgende scenario's voordoen:
- De verbinding is snel en stabiel voordat het plotseling stopt met werken. De time-out die is vereist totdat een pakket is gedeclareerd, is afhankelijk van de retourtijd (RTT) tussen de client en de sessiehost. Als de RTT laag is, kan één kant proberen om een pakket regelmatig opnieuw te verzenden, zodat de tijd die nodig is om 50 pogingen te bereiken minder is dan de gebruikelijke time-outwaarde van 17 seconden.
- Het pakket is groot. De maximale pakketgrootte die kan worden verzonden, is beperkt. De grootte van het pakket wordt uitgevoerd, maar het kan fluctueren en soms verkleinen. Als dat gebeurt, is het mogelijk dat het pakket dat wordt verzonden te groot is en consistent mislukt.
ConnectionBrokenMissedHeartbeatThresholdExceeded
Dit is een time-out op RDP-niveau. Vanwege een onjuiste configuratie wordt er soms een time-out op RDP-niveau geactiveerd voordat er een time-out op UDP-niveau optreedt.