Solucionar problemas do Shortpath RDP para redes públicas

Importante

No momento, o uso do shortpath RDP para redes públicas com TURN para a Área de Trabalho Virtual do Azure está em VERSÃO PRÉVIA. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.

Se você estiver tendo problemas ao usar o Shortpath RDP para redes públicas, use as informações neste artigo para ajudar a solucionar problemas.

Verificar a conectividade do servidor STUN/TURN e o tipo de NAT

Você pode validar a conectividade com os pontos de extremidade STUN/TURN e verificar se a funcionalidade básica do UDP está funcionando por meio do executável avdnettest.exe. Aqui está um link de download para a versão mais recente do avdnettest.exe.

Para executar o avdnettest.exe, clique duas vezes no arquivo ou execute-o na linha de comando. Se a conectividade for bem-sucedida, a saída será semelhante ao seguinte:

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.

Importante

Durante a versão prévia, TURN só está disponível para conexões com hosts de sessão em um pool de hosts de validação. Para configurar o pool de hosts como um ambiente de validação, confira Definir o pool de hosts como um ambiente de validação.

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 TCP, diferenciamos dois caminhos diferentes: o host da sessão para o gateway e o gateway para o cliente. Porém, isso não faz sentido para o UDP, pois não há um gateway. 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 não existe mais, mas não existe esse mecanismo 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 qualquer coisa com UDP. Portanto, a única maneira de saber que o par não existe mais é por uma mensagem de tempo limite.

ShortpathTransportReliabilityThresholdFailure

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

1. A conexão era muito rápida e estável antes de parar de funcionar de repente. O tempo limite necessário até que um pacote seja declarado perdido depende do RTT (tempo de viagem de ida e volta) entre o cliente e o host da sessão. Se o RTT for muito baixo, um lado poderá tentar reenviar um pacote com muita frequência. Portanto, o tempo necessário para atingir 50 tentativas pode ser menor do que o valor de tempo limite normal de 17 segundos.

2. O pacote é muito 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

Esse é um tempo limite no nível de RDP. Devido à configuração incorreta, o tempo limite de nível RDP às vezes disparava antes do tempo limite no nível UDP.