Risolvere i problemi relativi a RDP Shortpath per le reti pubbliche

Questo articolo illustra come risolvere i problemi relativi all'uso di Remote Desktop Protocol (RDP) Shortpath per le reti pubbliche.

Verificare la connettività del server STUN, TURN server e il tipo NAT

È possibile convalidare la connettività agli endpoint STUN e TURN e verificare che la funzionalità UDP (User Datagram Protocol) di base funzioni eseguendo il avdnettest.exe eseguibile. 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 è simile al seguente se la connettività ha esito positivo:

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.

Informazioni sugli errori registrate in Log Analytics

Ecco alcuni titoli di errore che potrebbero essere visualizzati in Log Analytics e cosa significano.

ShortpathTransportNetworkDrop

Per le connessioni TCP (Transmission Control Protocol), esistono due percorsi diversi:

• Dall'host di sessione al gateway
• Dal gateway al client

Tuttavia, per le connessioni UDP, questa differenza non è applicabile, perché non è coinvolto alcun 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 notifica al peer che la connessione TCP è scomparsa, ma non esiste alcun meccanismo di questo tipo per UDP.

La maggior parte degli errori di connessione, ad esempio ConnectionFailedClientDisconnect e ConnectionFailedServerDisconnect, è causata da pacchetti di reimpostazione TCP e 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 è veloce e stabile prima che si arresti improvvisamente il funzionamento. 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 RTT è basso, un lato può provare a inviare di nuovo un pacchetto di frequente, quindi il tempo necessario per raggiungere 50 tentativi può essere inferiore al valore di timeout consueto di 17 secondi.
• Il pacchetto è 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.