RDP vries oor VPN: insette werk nog, so toets die vervoerlaag

Wanneer die prent ophou opdateer maar die muis steeds oor die afgeleë lessenaar beweeg, is die ooglopende gevolgtrekking dat die VPN geval het. Daardie gevolgtrekking is gewoonlik verkeerd. ’n Bevrore raam met werkende insette beteken die sessie en sy insetkanaal leef, wat die fout na die grafiese vervoer skuif eerder as na roetebepaling of geloofsbriewe. Twee vinnige waarnemings skei die drie foute wat gebruikers met dieselfde woord beskryf.

Wat die vries vir jou nie sê nie

Afgeleë lessenaar dra insette en skermopdaterings oor TCP 3389, en huidige Windows-kliënte kan ’n UDP-vervoer byvoeg vir die grafies-swaar deel van die stroom. Op ’n tonnel wat groter datagramme fragmenteer of laat val, hou die betroubare kanaal aan om toetsaanslae te dra terwyl die grafiese kanaal vasval. Die resultaat is die vreemde kombinasie van ’n vasgevangde prent en ’n reageerende sleutelbord. Dit verduidelik ook waarom weer verbind soms die simptoom vir ’n minuut genees en dit dan terugbring.

’n Sessie wat ontkoppel en weer verbind, is ’n ander fout, en een wat glad nie oopmaak nie is ’n derde. Om eers die vorm te benoem, keer dat jy die verkeerde laag toets.

Skei die drie foute met twee opdragte

Bereikbaarheid is goedkoop om uit te skakel. Toets die RDP-poort vanaf die kliënt en lees dan die sessietoestand op die gasheer.

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

’n Mislukte TCP-toets beteken die sessie het nooit oopgemaak nie, so behandel dit as ’n brandmuur-, bereik- of diensprobleem eerder as ’n vries. ’n Suksesvolle toets met ’n aktiewe sessie bevestig die beheerkanaal bestaan, wat presies die bevrore-prent-geval is. Voer die gasheernavraag uit vanaf ’n rekening met toestemming om sessies te sien, want ’n toestemmingsfout lyk soos ’n leë lys. Teken die sessie-ID en toestand aan, aangesien ’n ontkoppelde sessie wat sy ID hou nie dieselfde as ’n aktiewe een is nie.

Skakel die UDP-vervoer af en vergelyk

As die skerm die enigste ding is wat vasval, vergelyk kliëntvervoer een verandering op ’n slag. Die ingeboude kliënt en die Store-kliënt deel nie ’n stapel nie, en die beleid hieronder verwyder UDP uit die ingeboude kliënt.

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

’n Waarde van 1 beteken UDP is reeds af vir daardie kliënt, so ’n vries wat die instelling oorleef is nie ’n UDP-padprobleem nie. Wanneer die waarde ontbreek, aktiveer die beleid, verbind weer en herhaal die presiese aksie wat voorheen gevries het. Toets die Store-kliënt as ’n aparte stap eerder as om albei veranderinge te kombineer, anders sal jy nie weet watter een saak gemaak het nie. Hou die kliëntweergawe in jou notas, want vervoergedrag het oor Windows-vrystellings heen verskuif.

Wanneer een gasheer vries maar die res reg is

’n Enkele foutiewe gasheer op ’n andersins gesonde subnet wys weg van die tonnel. Kontroleer die pad-MTU en die afgeleë skermstapel voordat jy VPN-instellings aanraak.

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

’n Antwoord bewys die pad dra ’n volgrootte pakket sonder fragmentering op daardie grootte, terwyl ’n mislukking met die do-not-fragment-vlag daarop dui dat die tonnel se MTU aandag nodig het. As 1472 grepe deurkom en net daardie gasheer vries, kyk na sy grafiese drywer en las eerder as na die netwerk. ’n Vinnige lêerkopie na dieselfde masjien sê iets oor deurset, nie oor die RDP-grafiese kanaal nie. Verander een veranderlike op ’n slag en herhaal dieselfde handeling op die skerm sodat die vergelyking iets beteken.

As die sessie glad nie oopmaak nie, stop hier, want dit is bereikbaarheid eerder as ’n vries. Andersins hou die vervoerinstelling wat die simptoom verander het en teken dit saam met die kliëntweergawe aan.