RDP-bevriezing via VPN: invoer werkt nog, dus test het transport

Wanneer het beeld stopt met vernieuwen maar de muis nog over de externe desktop glijdt, is de voor de hand liggende conclusie dat de VPN is weggevallen. Die conclusie is meestal onjuist. Een bevroren frame met werkende invoer betekent dat de sessie en het invoerkanaal leven, wat de fout richting grafiektransport duwt en niet richting routing of inloggegevens. Twee snelle observaties scheiden de drie storingen die gebruikers met hetzelfde woord beschrijven.

Wat de bevriezing u niet vertelt

Extern bureaublad draagt invoer en schermupdates over TCP 3389, en huidige Windows-clients kunnen een UDP-transport toevoegen voor het grafisch zware deel van de stream. Op een tunnel die grotere datagrammen fragmenteert of laat vallen, blijft het betrouwbare kanaal toetsaanslagen dragen terwijl het grafiekkanaal vastloopt. Het resultaat is de vreemde combinatie van een vastgelopen beeld en een toetsenbord dat reageert. Dat verklaart ook waarom opnieuw verbinden het symptoom soms een minuut geneest en het daarna terughaalt.

Een sessie die verbreekt en opnieuw verbindt is een andere storing, en een die helemaal niet opent is een derde. Als u eerst de vorm benoemt, test u niet de verkeerde laag.

Scheid de drie storingen met twee opdrachten

Bereikbaarheid uitsluiten is goedkoop. Test de RDP-poort vanaf de client en lees daarna de sessiestatus op de host.

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

Een mislukte TCP-test betekent dat de sessie nooit is geopend, dus behandel het als een firewall-, bereik- of serviceprobleem en niet als een bevriezing. Een geslaagde test met een actieve sessie bevestigt dat het besturingskanaal bestaat, wat precies het geval van het bevroren beeld is. Voer de hostquery uit vanaf een account dat sessies mag zien, want een rechtenfout ziet eruit als een lege lijst. Noteer de sessie-ID en de status, omdat een verbroken sessie die zijn ID houdt niet hetzelfde is als een actieve.

Schakel het UDP-transport uit en vergelijk

Als alleen het beeld vastloopt, vergelijk dan clienttransporten met één wijziging tegelijk. De ingebouwde client en de Store-client delen geen stack, en het beleid hieronder haalt UDP uit de ingebouwde client.

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

Een waarde van 1 betekent dat UDP voor die client al uit staat, dus een bevriezing die de instelling overleeft is geen UDP-padprobleem. Als de waarde ontbreekt, schakelt u het beleid in, verbindt u opnieuw en herhaalt u precies de actie die eerder bevroor. Test de Store-client als aparte stap in plaats van beide wijzigingen te combineren, anders weet u niet welke ertoe deed. Houd de clientversie in uw notities, want transportgedrag is tussen Windows-versies verschoven.

Wanneer één host bevriest maar de rest goed is

Eén falende host op een verder gezond subnet wijst weg van de tunnel. Controleer de MTU van het pad en de stack van de externe weergave voordat u VPN-instellingen aanraakt.

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

Een antwoord bewijst dat het pad een pakket van volledige grootte zonder fragmentatie op die grootte draagt, terwijl een fout met de do-not-fragment-vlag suggereert dat de MTU van de tunnel aandacht nodig heeft. Als 1472 bytes doorkomen en alleen die host bevriest, kijk dan naar de grafische driver en de belasting in plaats van het netwerk. Een snelle bestandskopie naar dezelfde machine zegt iets over doorvoer, niet over het RDP-grafiekkanaal. Wijzig één variabele tegelijk en herhaal dezelfde handeling op het scherm, zodat de vergelijking iets betekent.

Als de sessie helemaal niet opent, stop dan hier, want dat is bereikbaarheid en geen bevriezing. Anders houdt u de transportinstelling die het symptoom veranderde en noteert u die samen met de clientversie.