Blocarea RDP prin VPN: intrarea încă funcționează, așa că testați transportul

Când imaginea nu se mai actualizează, dar mouse-ul alunecă în continuare pe desktopul la distanță, concluzia evidentă este că VPN-ul a căzut. Această concluzie este de obicei greșită. Un cadru înghețat cu intrare funcțională înseamnă că sesiunea și canalul ei de intrare sunt vii, ceea ce împinge defectul spre transportul graficii, nu spre rutare sau acreditări. Două observații rapide separă cele trei defecte pe care utilizatorii le descriu cu același cuvânt.

Ce nu vă spune înghețarea

Desktopul la distanță transportă intrarea și actualizările ecranului prin TCP 3389, iar clienții Windows actuali pot adăuga un transport UDP pentru partea fluxului cu încărcare grafică mare. Pe un tunel care fragmentează sau aruncă datagrame mai mari, canalul fiabil continuă să transporte apăsările de taste în timp ce canalul grafic se blochează. Rezultatul este combinația stranie dintre o imagine blocată și o tastatură care răspunde. Acest lucru explică și de ce reconectarea vindecă uneori simptomul pentru un minut și apoi îl readuce.

O sesiune care se deconectează și se reconectează este un alt defect, iar una care nu se deschide deloc este a treia. Dacă numiți mai întâi forma, nu testați stratul greșit.

Separați cele trei defecte cu două comenzi

Excluderea accesibilității este ieftină. Testați portul RDP din client, apoi citiți starea sesiunii pe gazdă.

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

Un test TCP eșuat înseamnă că sesiunea nu s-a deschis niciodată, așa că tratați-l ca o problemă de firewall, arie de acoperire sau serviciu, nu ca o înghețare. Un test reușit cu o sesiune activă confirmă că canalul de control există, ceea ce este exact cazul imaginii înghețate. Rulați interogarea gazdei dintr-un cont care are permisiunea să vadă sesiuni, pentru că o eroare de permisiuni arată ca o listă goală. Notați ID-ul și starea sesiunii, deoarece o sesiune deconectată care își păstrează ID-ul nu este același lucru cu una activă.

Dezactivați transportul UDP și comparați

Dacă doar afișarea se blochează, comparați transporturile clienților cu o singură modificare pe rând. Clientul încorporat și clientul Store nu împart aceeași stivă, iar politica de mai jos elimină UDP din clientul încorporat.

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

O valoare de 1 înseamnă că UDP este deja oprit pentru acel client, așa că o înghețare care supraviețuiește setării nu este o problemă a căii UDP. Când valoarea lipsește, activați politica, reconectați-vă și repetați exact acțiunea care înghețase înainte. Testați clientul Store ca pas separat în loc să combinați ambele modificări, altfel nu veți ști care a contat. Păstrați versiunea clientului în notițe, deoarece comportamentul transportului s-a schimbat între versiunile Windows.

Când o gazdă îngheață, dar restul sunt în regulă

O singură gazdă defectă într-o subrețea altfel sănătoasă indică departe de tunel. Verificați MTU-ul căii și stiva afișării la distanță înainte de a atinge setările VPN.

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

Un răspuns dovedește că calea transportă un pachet de dimensiune completă fără fragmentare la acea dimensiune, în timp ce o eșuare cu steagul de nu fragmenta sugerează că MTU-ul tunelului are nevoie de atenție. Dacă trec 1472 de octeți și îngheață doar acea gazdă, uitați-vă la driverul grafic și la încărcarea ei, nu la rețea. O copiere rapidă de fișier către aceeași mașină spune ceva despre debit, nu despre canalul grafic RDP. Schimbați o variabilă pe rând și repetați aceeași acțiune pe ecran pentru ca comparația să însemne ceva.

Dacă sesiunea nu se deschide deloc, opriți-vă aici, pentru că aceasta este accesibilitate, nu înghețare. În caz contrar, păstrați setarea de transport care a schimbat simptomul și notați-o împreună cu versiunea clientului.