RDP-fagyás VPN-en át: a bemenet még működik, ezért tesztelje az átvitelt

Amikor a kép leáll a frissítéssel, de az egér továbbra is elsiklik a távoli asztalon, a kézenfekvő következtetés az, hogy a VPN megszakadt. Ez a következtetés általában téves. A működő bemenettel rendelkező fagyott képkocka azt jelenti, hogy a munkamenet és annak bemeneti csatornája él, ami a hibát a grafikai átvitel felé tolja, nem az útválasztás vagy a hitelesítő adatok felé. Két gyors megfigyelés különíti el azt a három hibát, amelyet a felhasználók ugyanazzal a szóval írnak le.

Amit a fagyás nem mond el

A távoli asztal a bemenetet és a képernyőfrissítéseket TCP 3389-en szállítja, és a jelenlegi Windows-ügyfelek UDP-átvitelt adhatnak hozzá az adatfolyam grafikailag nehéz részéhez. Olyan alagúton, amely a nagyobb datagramokat töredezi vagy eldobja, a megbízható csatorna tovább szállítja a billentyűleütéseket, miközben a grafikai csatorna megakad. Az eredmény a beragadt kép és a reagáló billentyűzet furcsa kombinációja. Ez azt is megmagyarázza, miért gyógyítja néha az újracsatlakozás a tünetet egy percre, majd hozza vissza.

A bontakozó és újracsatlakozó munkamenet másik hiba, és az, amelyik egyáltalán nem nyílik meg, a harmadik. Ha először megnevezi a formát, nem a rossz réteget teszteli.

Különítse el a három hibát két paranccsal

Az elérhetőség kizárása olcsó. Tesztelje az RDP-portot az ügyféltől, majd olvassa le a munkamenet állapotát a gazdagépen.

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

A sikertelen TCP-teszt azt jelenti, hogy a munkamenet soha nem nyílt meg, ezért kezelje tűzfal-, hatókör- vagy szolgáltatásproblémaként, nem fagyásként. A sikeres teszt aktív munkamenettel megerősíti, hogy a vezérlőcsatorna létezik, ami pontosan a fagyott kép esete. Futtassa a gazdagép-lekérdezést olyan fiókból, amely jogosult a munkamenetek látására, mert az engedélyhiba üres listának látszik. Jegyezze fel a munkamenet ID-jét és állapotát, mivel a leválasztott munkamenet, amely megtartja az ID-jét, nem ugyanaz, mint az aktív.

Kapcsolja ki az UDP-átvitelt, és hasonlítsa össze

Ha csak a kijelző akad meg, hasonlítsa össze az ügyfélátviteleket egyszerre egy változtatással. A beépített ügyfél és a Store-ügyfél nem osztozik veremen, és az alábbi szabályzat eltávolítja az UDP-t a beépített ügyfélből.

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

Az 1 érték azt jelenti, hogy az UDP már ki van kapcsolva annál az ügyfélnél, így a beállítást túlélő fagyás nem UDP-útvonal-probléma. Ha az érték hiányzik, engedélyezze a szabályzatot, csatlakozzon újra, és ismételje meg pontosan azt a műveletet, amely korábban lefagyott. A Store-ügyfelet külön lépésként tesztelje ahelyett, hogy a két változtatást kombinálná, különben nem tudja, melyik számított. Tartsa az ügyfélverziót a jegyzeteiben, mert az átvitel viselkedése a Windows-kiadások között változott.

Amikor egy gazdagép lefagy, a többi viszont rendben van

Egyetlen hibás gazdagép egy egyébként egészséges alhálózaton az alagúttól elfelé mutat. Ellenőrizze az útvonal MTU-ját és a távoli kijelző vermét, mielőtt hozzányúl a VPN-beállításokhoz.

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

Egy válasz bizonyítja, hogy az útvonal teljes méretű csomagot szállít töredezés nélkül ezen a méreten, míg a töredezést tiltó jelzővel járó hiba arra utal, hogy az alagút MTU-ja figyelmet igényel. Ha 1472 bájt átmegy, és csak az a gazdagép fagy le, nézze a grafikus illesztőprogramját és a terhelését, ne a hálózatot. Egy gyors fájlmásolás ugyanarra a gépre valamit mond az áteresztőképességről, nem az RDP grafikai csatornájáról. Egyszerre egy változót módosítson, és ismételje ugyanazt a képernyőn végzett műveletet, hogy az összehasonlításnak legyen értelme.

Ha a munkamenet egyáltalán nem nyílik meg, álljon meg itt, mert az elérhetőség, nem fagyás. Ellenkező esetben tartsa meg az átviteli beállítást, amely megváltoztatta a tünetet, és jegyezze fel az ügyfélverzióval együtt.