RDP-frysing over VPN: inndata verkar framleis, så test transporten

Når biletet sluttar å oppdatere, men musa framleis glir over fjernskrivebordet, er den openberre konklusjonen at VPN-en fall. Den konklusjonen er som regel feil. Ei frose ramme med fungerande inndata tyder på at økta og inndataskanelen er i live, noko som skyv feilen mot grafikktransporten og ikkje mot ruting eller påloggingsinformasjon. To raske observasjonar skil dei tre feila brukarane skildrar med same ord.

Kva frysninga ikkje fortel deg

Fjernskrivebord ber inndata og skjermoppdateringar over TCP 3389, og dagens Windows-klientar kan leggje til ein UDP-transport for den grafiktunge delen av straumen. På ein tunnel som fragmenterer eller slepp større datagram, held den pålitelege kanalen fram med å bere tastetrykk medan grafikkkanalen stoppar. Resultatet er den merkelege kombinasjonen av eit fastlåst bilete og eit tastatur som svarar. Det forklarer også kvifor gjentilkopling stundom kurerer symptomet i eitt minutt og deretter bringar det tilbake.

Ei økt som koplar frå og til igjen, er ein annan feil, og ei som aldri opnar, er ein tredje. Å namngje forma først hindrar deg i å teste feil lag.

Skil dei tre feila med to kommandoar

Tilgjenge er billeg å utelukke. Test RDP-porten frå klienten, og les deretter øktstilstanden på verten.

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

Ein mislukka TCP-test tyder på at økta aldri vart opna, så handsam det som eit brannmur-, område- eller tenesteproblem og ikkje som ei frysning. Ein vellukka test med ei aktiv økt stadfestar at kontrollkanalen finst, som er nøyaktig tilfellet med det frose biletet. Køyr vertsspørjinga frå ein konto som har løyve til å sjå økter, fordi ein løyvefeil ser ut som ei tom liste. Noter økt-ID og tilstand, sidan ei fråkopla økt som held på ID-en sin, ikkje er det same som ei aktiv.

Slå av UDP-transporten og samanlikn

Viss berre skjermbildet stoppar, samanlikn klienttransportar med éi endring om gongen. Den innebygde klienten og Store-klienten deler ikkje same stakk, og policyen nedanfor fjernar UDP frå den innebygde klienten.

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

Ein verdi på 1 tyder på at UDP allereie er av for den klienten, så ei frysning som overlever innstillinga, er ikkje eit UDP-stiproblem. Når verdien manglar, aktiver policyen, kopla til på nytt og gjenta nøyaktig handlinga som fraus før. Test Store-klienten som eit eige steg i staden for å kombinere begge endringane, elles veit du ikkje kva som betydde noko. Ta vare på klientversjonen i notata dine, fordi transportåtferd har endra seg mellom Windows-utgåver.

Når éin vert frys, men resten har det bra

Éin einaste feilande vert på eit elles sunt delnett peikar bort frå tunnelen. Kontroller MTU-en til banen og fjernskjermstakken før du rører VPN-innstillingar.

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

Eit svar beviser at banen ber ein pakke i full storleik utan fragmentering ved den storleiken, medan ein feil med do-not-fragment-flagg tyder på at MTU-en til tunnelen treng merksemd. Viss 1472 byte passerer og berre den verten frys, sjå på grafikkdrivaren og lasta i staden for nettverket. Ein rask filkopi til same maskin seier noko om gjennomstrøyming, ikkje om RDP-grafikkkanalen. Endre éin variabel om gongen og gjenta den same skjermhandlinga, slik at samanlikninga betyr noko.

Viss økta aldri opnar, stopp her, fordi det er tilgjenge og ikkje ei frysning. Elles behald transportinnstillinga som endra symptomet, og noter ho saman med klientversjonen.