RDP-frys over VPN: input virker stadig, så test transporten

Når billedet holder op med at opdatere, men musen stadig glider hen over fjernskrivebordet, er den oplagte konklusion, at VPN'en er faldet. Den konklusion er som regel forkert. En frossen ramme med fungerende input betyder, at sessionen og dens inputkanal er i live, hvilket skubber fejlen mod grafiktransporten frem for mod routing eller loginoplysninger. To hurtige observationer adskiller de tre fejl, som brugerne beskriver med det samme ord.

Hvad frysningen ikke fortæller dig

Fjernskrivebord bærer input og skærmopdateringer over TCP 3389, og nuværende Windows-klienter kan tilføje en UDP-transport til den grafikstunge del af strømmen. På en tunnel, der fragmenterer eller dropper større datagrammer, fortsætter den pålidelige kanal med at bære tastetryk, mens grafikanalen går i stå. Resultatet er den mærkelige kombination af et fastlåst billede og et tastatur, der reagerer. Det forklarer også, hvorfor genopkobling nogle gange kurerer symptomet i et minut og derefter bringer det tilbage.

En session, der afbryder og genopretter forbindelse, er en anden fejl, og en der slet ikke åbner, er en tredje. At navngive formen først forhindrer dig i at teste det forkerte lag.

Adskil de tre fejl med to kommandoer

Tilgængelighed er billig at udelukke. Test RDP-porten fra klienten, og læs derefter sessionstilstanden på værten.

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

En mislykket TCP-test betyder, at sessionen aldrig blev åbnet, så behandl det som et firewall-, scope- eller serviceproblem frem for en frysning. En vellykket test med en aktiv session bekræfter, at kontrolkanalen findes, hvilket netop er tilfældet med det frosne billede. Kør værtsforespørgslen fra en konto, der har tilladelse til at se sessioner, fordi en tilladelsesfejl ligner en tom liste. Notér sessions-ID og tilstand, da en afbrudt session, der beholder sit ID, ikke er det samme som en aktiv.

Slå UDP-transporten fra, og sammenlign

Hvis det kun er skærmbilledet, der går i stå, så sammenlign klienttransport én ændring ad gangen. Den indbyggede klient og Store-klienten deler ikke en stak, og politikken nedenfor fjerner UDP fra den indbyggede klient.

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

En værdi på 1 betyder, at UDP allerede er slået fra for den klient, så en frysning, der overlever indstillingen, er ikke et UDP-stiproblem. Når værdien mangler, skal du aktivere politikken, genoprette forbindelsen og gentage præcis den handling, der frøs før. Test Store-klienten som et separat trin i stedet for at kombinere begge ændringer, ellers ved du ikke, hvilken der betød noget. Gem klientversionen i dine noter, fordi transportadfærd har ændret sig gennem Windows-udgivelser.

Når én vært fryser, men resten har det fint

En enkelt fejlende vært på et ellers sundt undernet peger væk fra tunnelen. Kontroller stiens MTU og fjernskærmsstakken, før du rører ved VPN-indstillinger.

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

Et svar beviser, at stien bærer en pakke i fuld størrelse uden fragmentering ved den størrelse, mens en fejl med do-not-fragment-flaget tyder på, at tunnelens MTU trænger til opmærksomhed. Hvis 1472 byte passerer, og kun den vært fryser, så se på dens grafikdriver og belastning i stedet for netværket. En hurtig filkopi til den samme maskine siger noget om gennemstrømning, ikke om RDP-grafikkanalen. Ændr én variabel ad gangen, og gentag den samme handling på skærmen, så sammenligningen betyder noget.

Hvis sessionen slet ikke åbner, så stop her, fordi det er tilgængelighed og ikke en frysning. Ellers behold den transportindstilling, der ændrede symptomet, og notér den sammen med klientversionen.