Risolvere i problemi relativi a RDP Shortpath per le reti pubbliche
Se si verificano problemi durante l'uso di RDP Shortpath per le reti pubbliche, usare le informazioni contenute in questo articolo per risolvere i problemi.
Verifica della connettività del server STUN/TURN e del tipo NAT
È possibile convalidare la connettività agli endpoint STUN/TURN e verificare che la funzionalità UDP di base funzioni eseguendo l'eseguibile avdnettest.exe. Qui di seguito è fornito un link per il download alla versione più recente di avdnettest.exe.
È possibile eseguire avdnettest.exe facendo doppio clic sul file oppure eseguendolo dalla riga di comando. L'output sarà simile al seguente se la connettività ha esito positivo:
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.
Informazioni sugli errori registrate in Log Analytics
Ecco alcuni titoli di errore che potrebbero essere visualizzati in Log Analytics e cosa significano.
ShortpathTransportNetworkDrop
Per TCP si differenziano due percorsi diversi, ovvero l'host di sessione al gateway e il gateway al client, ma questo non ha senso per UDP perché non esiste un gateway. L'altra distinzione per TCP è che in molti casi uno degli endpoint, o forse un'infrastruttura al centro, genera un pacchetto di reimpostazione TCP (bit di controllo RST), che causa un arresto rigido della connessione TCP. Ciò funziona perché TCP RST (e anche TCP FIN per l'arresto normale) viene gestito dal sistema operativo e anche da alcuni router, ma non dall'applicazione. Ciò significa che se un'applicazione si arresta in modo anomalo, Windows informerà il peer che la connessione TCP è scomparsa, ma non esiste un meccanismo di questo tipo per UDP.
La maggior parte degli errori di connessione, ad esempio ConnectionFailedClientDisconnect e ConnectionFailedServerDisconnect, è causata da pacchetti di reimpostazione TCP, non da un timeout. Non c'è modo per il sistema operativo o un router di segnalare nulla con UDP, quindi l'unico modo per sapere che il peer è andato via è da un messaggio di timeout.
ShortpathTransportReliabilityThresholdFailure
Questo errore viene attivato se non viene eseguito un pacchetto specifico, anche se la connessione non è morta. Il pacchetto viene reinviato fino a 50 volte, quindi è improbabile, ma può verificarsi negli scenari seguenti:
La connessione era molto veloce e stabile prima che improvvisamente smettesse di funzionare. Il timeout necessario fino a quando non viene dichiarato perso un pacchetto dipende dal tempo di round trip (RTT) tra il client e l'host sessione. Se il RTT è molto basso, un lato può provare a inviare di nuovo un pacchetto molto frequentemente, quindi il tempo necessario per raggiungere 50 tentativi può essere inferiore al valore di timeout consueto di 17 secondi.
Il pacchetto è molto grande. La dimensione massima del pacchetto che può essere trasmessa è limitata. La dimensione del pacchetto viene sondata, ma può variare e talvolta ridursi. In tal caso, è possibile che il pacchetto inviato sia troppo grande e avrà esito negativo in modo coerente.
ConnectionBrokenMissedHeartbeatThresholdExceeded
Si tratta di un timeout a livello RDP. A causa di errori di configurazione, il timeout del livello RDP viene talvolta attivato prima del timeout a livello DI UDP.