Blocco di RDP su VPN: l’input funziona ancora, quindi provate il trasporto

Quando l’immagine smette di aggiornarsi ma il mouse continua a scorrere sul desktop remoto, la conclusione ovvia è che la VPN è caduta. Questa conclusione di solito è sbagliata. Un fotogramma congelato con input funzionante significa che la sessione e il suo canale di input sono vivi, il che spinge il guasto verso il trasporto grafico e non verso l’instradamento o le credenziali. Due osservazioni rapide separano i tre guasti che gli utenti descrivono con la stessa parola.

Cosa non vi dice il blocco

Il desktop remoto trasporta input e aggiornamenti dello schermo su TCP 3389, e i client Windows attuali possono aggiungere un trasporto UDP per la parte del flusso più pesante dal punto di vista grafico. Su un tunnel che frammenta o scarta datagrammi più grandi, il canale affidabile continua a trasportare le pressioni dei tasti mentre il canale grafico si blocca. Il risultato è la strana combinazione di un’immagine bloccata e una tastiera che risponde. Questo spiega anche perché riconnettersi a volte guarisce il sintomo per un minuto e poi lo riporta.

Una sessione che si disconnette e si riconnette è un guasto diverso, e una che non si apre mai è un terzo. Nominare prima la forma evita di testare lo strato sbagliato.

Separate i tre guasti con due comandi

Escludere la raggiungibilità costa poco. Provate la porta RDP dal client, poi leggete lo stato della sessione sull’host.

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

Un test TCP fallito significa che la sessione non si è mai aperta, quindi trattatelo come un problema di firewall, ambito o servizio e non come un blocco. Un test riuscito con una sessione attiva conferma che il canale di controllo esiste, che è esattamente il caso dell’immagine congelata. Eseguite la query sull’host da un account autorizzato a vedere le sessioni, perché un errore di autorizzazione sembra una lista vuota. Annotate l’ID e lo stato della sessione, dato che una sessione disconnessa che conserva il suo ID non è uguale a una attiva.

Disattivate il trasporto UDP e confrontate

Se si blocca solo la visualizzazione, confrontate i trasporti dei client con una modifica alla volta. Il client integrato e il client di Store non condividono lo stesso stack, e la politica sotto rimuove UDP dal client integrato.

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

Un valore di 1 significa che UDP è già disattivato per quel client, quindi un blocco che sopravvive all’impostazione non è un problema del percorso UDP. Quando il valore manca, attivate la politica, riconnettetevi e ripetete esattamente l’azione che si era bloccata. Provate il client di Store come passaggio separato invece di combinare le due modifiche, altrimenti non saprete quale contava. Tenete la versione del client nelle vostre note, perché il comportamento del trasporto è cambiato tra le versioni di Windows.

Quando un solo host si blocca ma gli altri vanno bene

Un solo host guasto su una sottorete per il resto sana punta lontano dal tunnel. Controllate l’MTU del percorso e lo stack della visualizzazione remota prima di toccare le impostazioni VPN.

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

Una risposta dimostra che il percorso trasporta un pacchetto di dimensioni piene senza frammentazione a quella dimensione, mentre un fallimento con il flag di non frammentazione suggerisce che l’MTU del tunnel richiede attenzione. Se passano 1472 byte e si blocca solo quell’host, guardate il suo driver grafico e il carico invece della rete. Una copia rapida di un file sulla stessa macchina dice qualcosa sulla velocità effettiva, non sul canale grafico di RDP. Cambiate una variabile alla volta e ripetete la stessa azione sullo schermo perché il confronto significhi qualcosa.

Se la sessione non si apre mai, fermatevi qui, perché è raggiungibilità e non un blocco. Altrimenti conservate l’impostazione di trasporto che ha cambiato il sintomo e annotatela con la versione del client.