Congelamento de RDP pela VPN: a entrada ainda funciona, então teste o transporte

Quando a imagem deixa de atualizar mas o rato continua a deslizar pelo ambiente de trabalho remoto, a conclusão óbvia é que a VPN caiu. Essa conclusão normalmente está errada. Um fotograma congelado com entrada funcional significa que a sessão e o seu canal de entrada estão vivos, o que empurra a falha para o transporte gráfico e não para o encaminhamento ou as credenciais. Duas observações rápidas separam as três falhas que os utilizadores descrevem com a mesma palavra.

O que o congelamento não lhe diz

O ambiente de trabalho remoto transporta entrada e atualizações de ecrã por TCP 3389, e os clientes Windows atuais podem acrescentar um transporte UDP para a parte do fluxo mais pesada em gráficos. Num túnel que fragmenta ou descarta datagramas maiores, o canal fiável continua a transportar teclas enquanto o canal gráfico encrava. O resultado é a estranha combinação de uma imagem presa e um teclado que responde. Isto também explica porque reconectar às vezes cura o sintoma durante um minuto e depois o traz de volta.

Uma sessão que se desliga e volta a ligar é outra falha, e uma que nunca abre é uma terceira. Nomear primeiro a forma evita testar a camada errada.

Separe as três falhas com dois comandos

Descartar a acessibilidade é barato. Teste a porta RDP a partir do cliente e depois leia o estado da sessão no host.

Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-host

Um teste TCP falhado significa que a sessão nunca abriu, por isso trate-o como um problema de firewall, âmbito ou serviço e não como um congelamento. Um teste bem-sucedido com uma sessão ativa confirma que o canal de controlo existe, que é exatamente o caso da imagem congelada. Execute a consulta ao host a partir de uma conta autorizada a ver sessões, porque um erro de permissões parece uma lista vazia. Registe o ID e o estado da sessão, pois uma sessão desligada que mantém o seu ID não é o mesmo que uma ativa.

Desative o transporte UDP e compare

Se apenas a apresentação encrava, compare transportes de cliente com uma alteração de cada vez. O cliente integrado e o cliente da Store não partilham a mesma pilha, e a política abaixo remove o UDP do cliente integrado.

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP

Um valor de 1 significa que o UDP já está desligado para esse cliente, por isso um congelamento que sobrevive à definição não é um problema do caminho UDP. Quando o valor falta, ative a política, volte a ligar e repita exatamente a ação que congelou antes. Teste o cliente da Store como passo separado em vez de combinar as duas alterações, ou não saberá qual foi importante. Guarde a versão do cliente nas suas notas, porque o comportamento do transporte mudou entre versões do Windows.

Quando um host congela mas os restantes estão bem

Um único host com falha numa sub-rede de resto saudável aponta para longe do túnel. Verifique a MTU do caminho e a pilha de visualização remota antes de tocar nas definições da VPN.

ping -f -l 1472 rdp-host.example.com

Uma resposta prova que o caminho transporta um pacote de tamanho completo sem fragmentação nesse tamanho, enquanto uma falha com o sinalizador de não fragmentar sugere que a MTU do túnel precisa de atenção. Se passarem 1472 bytes e só esse host congelar, olhe para o controlador gráfico e a carga dele em vez da rede. Uma cópia rápida de ficheiro para a mesma máquina diz algo sobre o débito, não sobre o canal gráfico do RDP. Altere uma variável de cada vez e repita a mesma ação no ecrã para que a comparação signifique algo.

Se a sessão nunca abre, pare aqui, porque isso é acessibilidade e não um congelamento. Caso contrário, mantenha a definição de transporte que mudou o sintoma e registe-a com a versão do cliente.