RDP-frysing over VPN: inndata virker fortsatt, så test transporten

Når bildet slutter å oppdateres, men musen fortsatt glir over fjernskrivebordet, er den åpenbare konklusjonen at VPN-en falt. Den konklusjonen er som regel feil. En frossen ramme med fungerende inndata betyr at sesjonen og inndataskanalen er i live, noe som skyver feilen mot grafikktransporten og ikke mot ruting eller påloggingsinformasjon. To raske observasjoner skiller de tre feilene brukerne beskriver med samme ord.

Hva frysingen ikke forteller deg

Fjernskrivebord bærer inndata og skjermoppdateringer over TCP 3389, og dagens Windows-klienter kan legge til en UDP-transport for den grafiktunge delen av strømmen. På en tunnel som fragmenterer eller slipper større datagrammer, fortsetter den pålitelige kanalen å bære tastetrykk mens grafikkkanalen stopper. Resultatet er den merkelige kombinasjonen av et fastlåst bilde og et tastatur som svarer. Det forklarer også hvorfor gjentilkobling noen ganger kurerer symptomet i et minutt og deretter bringer det tilbake.

En sesjon som kobles fra og til igjen, er en annen feil, og en som aldri åpnes, er en tredje. Å navngi formen først hindrer deg i å teste feil lag.

Skill de tre feilene med to kommandoer

Tilgjengelighet er billig å utelukke. Test RDP-porten fra klienten, og les deretter sesjonstilstanden på verten.

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

En mislykket TCP-test betyr at sesjonen aldri ble åpnet, så behandle det som et brannmur-, område- eller tjenesteproblem og ikke som en frysing. En vellykket test med en aktiv sesjon bekrefter at kontrollkanalen finnes, som er nøyaktig tilfellet med det frosne bildet. Kjør vertsspørringen fra en konto som har tillatelse til å se sesjoner, fordi en tillatelsesfeil ser ut som en tom liste. Noter sesjons-ID og tilstand, siden en frakoblet sesjon som beholder ID-en sin, ikke er det samme som en aktiv.

Slå av UDP-transporten og sammenlign

Hvis bare skjermbildet stopper, sammenlign klienttransportene med én endring om gangen. Den innebygde klienten og Store-klienten deler ikke samme stakk, og policyen nedenfor fjerner UDP fra den innebygde klienten.

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

En verdi på 1 betyr at UDP allerede er av for den klienten, så en frysing som overlever innstillingen, er ikke et UDP-stiproblem. Når verdien mangler, aktiver policyen, koble til på nytt og gjenta nøyaktig handlingen som frøs før. Test Store-klienten som et eget trinn i stedet for å kombinere begge endringene, ellers vet du ikke hvilken som betydde noe. Ta vare på klientversjonen i notatene dine, fordi transportatferd har endret seg mellom Windows-utgivelser.

Når én vert fryser, men resten har det bra

Én enkelt feilende vert på et ellers sunt delnett peker bort fra tunnelen. Kontroller banens MTU og fjernskjermstakken før du rører VPN-innstillinger.

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

Et svar beviser at banen bærer en pakke i full størrelse uten fragmentering ved den størrelsen, mens en feil med do-not-fragment-flagget tyder på at tunnelens MTU trenger oppmerksomhet. Hvis 1472 byte passerer og bare den verten fryser, se på grafikkdriveren og lasten i stedet for nettverket. En rask filkopi til samme maskin sier noe om gjennomstrømning, ikke om RDP-grafikkkanalen. Endre én variabel om gangen og gjenta den samme skjermhandlingen, slik at sammenligningen betyr noe.

Hvis sesjonen aldri åpnes, stopp her, fordi det er tilgjengelighet og ikke en frysing. Ellers behold transportinnstillingen som endret symptomet, og noter den sammen med klientversjonen.