RDP-frysning över VPN: inmatningen fungerar fortfarande, så testa transporten

När bilden slutar uppdateras men musen fortfarande glider över fjärrskrivbordet är den uppenbara slutsatsen att VPN:en föll. Den slutsatsen är oftast fel. En fryst bildruta med fungerande inmatning betyder att sessionen och dess inmatningskanal lever, vilket skjuter felet mot grafiktransporten och inte mot routning eller inloggningsuppgifter. Två snabba observationer skiljer de tre fel som användare beskriver med samma ord.

Vad frysningen inte berättar för dig

Fjärrskrivbord bär inmatning och skärmuppdateringar över TCP 3389, och nuvarande Windows-klienter kan lägga till en UDP-transport för den grafikintensiva delen av strömmen. På en tunnel som fragmenterar eller tappar större datagram fortsätter den tillförlitliga kanalen att bära tangenttryckningar medan grafikanalen stannar. Resultatet är den märkliga kombinationen av en fastlåst bild och ett tangentbord som svarar. Det förklarar också varför återanslutning ibland botar symtomet i en minut och sedan tar tillbaka det.

En session som kopplas från och återansluter är ett annat fel, och en som aldrig öppnas är ett tredje. Att namnge formen först hindrar dig från att testa fel lager.

Skilj de tre felen med två kommandon

Tillgänglighet är billigt att utesluta. Testa RDP-porten från klienten och läs sedan sessionsstatusen på värden.

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

Ett misslyckat TCP-test betyder att sessionen aldrig öppnades, så behandla det som ett brandväggs-, omfångs- eller tjänsteproblem och inte som en frysning. Ett lyckat test med en aktiv session bekräftar att kontrollkanalen finns, vilket är precis fallet med den frysta bilden. Kör värdbegäran från ett konto som har behörighet att se sessioner, eftersom ett behörighetsfel ser ut som en tom lista. Anteckna sessions-ID och tillstånd, eftersom en frånkopplad session som behåller sitt ID inte är detsamma som en aktiv.

Stäng av UDP-transporten och jämför

Om bara skärmbilden fastnar, jämför klienttransporter med en ändring i taget. Den inbyggda klienten och Store-klienten delar inte samma stack, och policyn nedan tar bort UDP från den inbyggda klienten.

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

Värdet 1 betyder att UDP redan är av för den klienten, så en frysning som överlever inställningen är inte ett UDP-vägproblem. När värdet saknas, aktivera policyn, återanslut och upprepa exakt den åtgärd som frös tidigare. Testa Store-klienten som ett separat steg i stället för att kombinera båda ändringarna, annars vet du inte vilken som spelade roll. Behåll klientversionen i dina anteckningar, eftersom transportbeteendet har ändrats mellan Windows-versioner.

När en värd fryser men resten är bra

En enda felande värd i ett i övrigt friskt subnät pekar bort från tunneln. Kontrollera banans MTU och fjärrskärmens stack innan du rör VPN-inställningarna.

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

Ett svar bevisar att banan bär ett paket i full storlek utan fragmentering vid den storleken, medan ett misslyckande med do-not-fragment-flaggan tyder på att tunnelns MTU behöver uppmärksamhet. Om 1472 byte passerar och bara den värden fryser, titta på dess grafikdrivrutin och last i stället för nätverket. En snabb filkopiering till samma maskin säger något om genomströmning, inte om RDP-grafikkanalen. Ändra en variabel i taget och upprepa samma skärmåtgärd så att jämförelsen betyder något.

Om sessionen aldrig öppnas, stanna här, eftersom det är tillgänglighet och inte en frysning. Annars behåll transportinställningen som ändrade symtomet och anteckna den tillsammans med klientversionen.