Bloqueig d’RDP per VPN: l’entrada encara funciona, així que proveu el transport

Quan la imatge deixa d’actualitzar-se però el ratolí continua lliscant per l’escriptori remot, la conclusió òbvia és que la VPN ha caigut. Aquesta conclusió sol ser errònia. Un fotograma congelat amb entrada funcional significa que la sessió i el seu canal d’entrada són vius, cosa que empeny la fallada cap al transport gràfic i no cap a l’encaminament ni les credencials. Dues observacions ràpides separen les tres fallades que els usuaris descriuen amb la mateixa paraula.

Què no us diu el bloqueig

L’escriptori remot porta l’entrada i les actualitzacions de pantalla per TCP 3389, i els clients actuals de Windows poden afegir un transport UDP per a la part de flux amb més càrrega gràfica. En un túnel que fragmenta o descarta datagrames més grans, el canal fiable continua portant pulsacions de tecles mentre el canal gràfic s’encalla. El resultat és la combinació estranya d’una imatge encallada i un teclat que respon. També explica per què reconnectar de vegades cura el símptoma durant un minut i després el torna.

Una sessió que es desconnecta i es reconnecta és una fallada diferent, i una que no s’obre mai és una tercera. Nomenar primer la forma evita que proveu la capa equivocada.

Separeu les tres fallades amb dues ordres

Descartar l’abastabilitat és barat. Proveu el port RDP des del client i després llegiu l’estat de la sessió a l’amfitrió.

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

Una prova TCP fallida vol dir que la sessió no es va obrir mai, així que tracteu-ho com un problema de tallafocs, abast o servei i no com un bloqueig. Una prova correcta amb una sessió activa confirma que el canal de control existeix, que és exactament el cas de la imatge congelada. Executeu la consulta a l’amfitrió des d’un compte amb permís per veure sessions, perquè un error de permisos sembla una llista buida. Anoteu l’ID i l’estat de la sessió, ja que una sessió desconnectada que conserva el seu ID no és el mateix que una d’activa.

Desactiveu el transport UDP i compareu

Si només s’encalla la pantalla, compareu transports de client amb un canvi cada vegada. El client integrat i el client de Store no comparteixen pila, i la política de sota treu UDP del client integrat.

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

Un valor d’1 vol dir que UDP ja està desactivat per a aquest client, així que un bloqueig que sobreviu al paràmetre no és un problema del camí UDP. Quan el valor falta, activeu la política, reconnecteu i repetiu exactament l’acció que es va congelar abans. Proveu el client de Store com a pas a part en lloc de combinar els dos canvis, o no sabreu quin va importar. Guardeu la versió del client a les notes, perquè el comportament del transport ha canviat entre versions de Windows.

Quan un amfitrió es bloqueja i la resta van bé

Un sol amfitrió fallit en una subxarxa sana apunta lluny del túnel. Comproveu l’MTU del camí i la pila de pantalla remota abans de tocar la configuració de la VPN.

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

Una resposta demostra que el camí porta un paquet de mida completa sense fragmentació a aquesta mida, mentre que una fallada amb el senyal de no fragmentar suggereix que l’MTU del túnel necessita atenció. Si passen 1472 bytes i només es bloqueja aquest amfitrió, mireu el seu controlador gràfic i la càrrega en lloc de la xarxa. Una còpia ràpida d’un fitxer a la mateixa màquina diu alguna cosa sobre el rendiment, no sobre el canal gràfic d’RDP. Canvieu una variable cada vegada i repetiu la mateixa acció en pantalla perquè la comparació signifiqui alguna cosa.

Si la sessió no s’obre mai, atureu-vos aquí, perquè això és abastabilitat i no un bloqueig. Si no, conserveu el paràmetre de transport que va canviar el símptoma i anoteu-lo amb la versió del client.