Congelación de RDP por VPN: a entrada segue funcionando, así que probe o transporte

Cando a imaxe deixa de actualizarse pero o rato segue deslizándose polo escritorio remoto, a conclusión obvia é que a VPN caeu. Esa conclusión adoita ser errónea. Un fotograma conxelado con entrada funcional significa que a sesión e o seu canal de entrada están vivos, o que empurra o fallo cara ao transporte gráfico e non cara ao encamiñamento ou ás credenciais. Dúas observacións rápidas separan os tres fallos que os usuarios describen coa mesma palabra.

Que non lle di a conxelación

O escritorio remoto transporta a entrada e as actualizacións de pantalla por TCP 3389, e os clientes actuais de Windows poden engadir un transporte UDP para a parte do fluxo con máis carga gráfica. Nun túnel que fragmenta ou descarta datagramas máis grandes, o canal fiable segue levando pulsacións de teclas mentres o canal gráfico atasca. O resultado é a estraña combinación dunha imaxe trabada e un teclado que responde. Tamén explica por que reconectar ás veces cura o síntoma durante un minuto e despois volve.

Unha sesión que se desconecta e se reconecta é outro fallo, e unha que nunca se abre é un terceiro. Nomear primeiro a forma evita que probe a capa equivocada.

Separe os tres fallos con dous comandos

Descartar a accesibilidade é barato. Probe o porto RDP desde o cliente e despois lea o estado da sesión no host.

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

Unha proba TCP fallida significa que a sesión nunca se abriu, así que tráteo como un problema de cortafuegos, ámbito ou servizo e non como unha conxelación. Unha proba correcta cunha sesión activa confirma que o canal de control existe, que é exactamente o caso da imaxe conxelada. Execute a consulta ao host desde unha conta con permiso para ver sesións, porque un erro de permisos parece unha lista baleira. Anote o ID e o estado da sesión, xa que unha sesión desconectada que conserva o seu ID non é o mesmo ca unha activa.

Desactive o transporte UDP e compare

Se só atasca a pantalla, compare transportes de cliente cun cambio cada vez. O cliente integrado e o cliente de Store non comparten pila, e a política de abaixo quita UDP do cliente integrado.

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

Un valor de 1 significa que UDP xa está desactivado para ese cliente, así que unha conxelación que sobrevive ao axuste non é un problema da ruta UDP. Cando falta o valor, active a política, reconecte e repita exactamente a acción que se conxelou antes. Probe o cliente de Store como paso aparte en lugar de combinar os dous cambios, ou non saberá cal importou. Garde a versión do cliente nas súas notas, porque o comportamento do transporte cambiou entre versións de Windows.

Cando un host se conxela pero o resto está ben

Un só host defectuoso nunha subrede por demais sana apunta lonxe do túnel. Comprobe a MTU da ruta e a pila de pantalla remota antes de tocar a configuración da VPN.

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

Unha resposta demostra que a ruta leva un paquete de tamaño completo sen fragmentación a ese tamaño, mentres que un fallo coa marca de non fragmentar suxire que a MTU do túnel necesita atención. Se pasan 1472 bytes e só se conxela ese host, mire o seu controlador gráfico e a súa carga en lugar da rede. Unha copia rápida dun ficheiro á mesma máquina di algo sobre o rendemento, non sobre o canal gráfico de RDP. Cambie unha variable cada vez e repita a mesma acción en pantalla para que a comparación signifique algo.

Se a sesión nunca se abre, detéñase aquí, porque iso é accesibilidade e non unha conxelación. De non ser así, conserve o axuste de transporte que cambiou o síntoma e anóteo coa versión do cliente.