Solucionar problemas do Shortpath RDP para redes públicas

Artigo
01/22/2025

Este artigo ajuda a solucionar problemas ao usar o caminho curto do protocolo RDP para redes públicas.

Verifique a conectividade do servidor STUN, TURN e o tipo de NAT

Você pode validar a conectividade com os pontos de extremidade STUN e TURN e verificar se a funcionalidade básica do User Datagram Protocol (UDP) funciona executando o avdnettest.exe executável. Aqui está um link de download para a versão mais recente do avdnettest.exe.

Você pode executar avdnettest.exe clicando duas vezes no arquivo ou executando-o na linha de comando. A saída será semelhante a esta se a conectividade for bem-sucedida:

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.

Informações de erro registradas no Log Analytics

Aqui estão alguns títulos de erro que você pode ver registrados no Log Analytics e o que eles significam.

ShortpathTransportNetworkDrop

Para conexões TCP, há dois caminhos diferentes:

Do host da sessão para o gateway
Do gateway para o cliente

No entanto, para conexões UDP, essa diferença não é aplicável, pois não há gateway envolvido. A outra distinção para TCP é que, em muitos casos, um dos pontos de extremidade, ou talvez alguma infraestrutura no meio, gera um pacote de redefinição de TCP (bit de controle RST), o que causa um desligamento rígido da conexão TCP. Isso funciona porque o TCP RST (e também o TCP FIN para desligamento normal) é tratado pelo sistema operacional e também por alguns roteadores, mas não pelo aplicativo. Isso significa que, se um aplicativo falhar, o Windows notificará o par de que a conexão TCP desapareceu, mas esse mecanismo não existe para UDP.

A maioria dos erros de conexão, como ConnectionFailedClientDisconnect e ConnectionFailedServerDisconnect, são causados por pacotes de redefinição de TCP, não por um tempo limite. Não há como o sistema operacional ou um roteador sinalizar nada com UDP, então a única maneira de saber que o peer desapareceu é por uma mensagem de tempo limite.

ShortpathTransportReliabilityThresholdFailure

Esse erro é acionado se um pacote específico não passar, mesmo que a conexão não esteja morta. O pacote é reenviado até 50 vezes, portanto, é improvável, mas pode acontecer nos seguintes cenários:

A conexão é rápida e estável antes de parar de funcionar repentinamente. O tempo limite necessário até que um pacote seja declarado perdido depende do tempo de ida e volta (RTT) entre o cliente e o host da sessão. Se o RTT estiver baixo, um lado pode tentar reenviar um pacote com frequência, portanto, o tempo necessário para atingir 50 tentativas pode ser menor que o valor de tempo limite normal de 17 segundos.
O pacote é grande. O tamanho máximo do pacote que pode ser transmitido é limitado. O tamanho do pacote é investigado, mas pode flutuar e, às vezes, reduzir. Se isso acontecer, é possível que o pacote que está sendo enviado seja muito grande e falhe consistentemente.

ConnectionBrokenMissedHeartbeatThresholdExceeded

Este é um tempo limite de nível RDP. Devido à configuração incorreta, o tempo limite do nível RDP às vezes era acionado antes do tempo limite do nível UDP.

Compartilhar via