Երբ պատկերը դադարում է թարմացվել, բայց մկնիկը դեռ սահում է հեռավոր աշխատասեղանի վրայով, ակնհայտ եզրակացությունն այն է, որ VPN-ը կտրվել է։ Այդ եզրակացությունը սովորաբար սխալ է։ Աշխատող մուտքով սառած կադրը նշանակում է, որ նստաշրջանը և դրա մուտքի ուղին կենդանի են, ինչը խափանումը մղում է դեպի գրաֆիկայի փոխադրում, այլ ոչ թե դեպի երթուղավորում կամ հավատարմագրեր։ Երկու արագ դիտարկում բաժանում են երեք խափանումները, որոնք օգտատերերը նկարագրում են նույն բառով։

Ինչ չի ասում ձեզ սառչելը

Հեռավոր աշխատասեղանը մուտքը և էկրանի թարմացումները փոխանցում է TCP 3389-ով, և ներկա Windows հաճախորդները կարող են ավելացնել UDP փոխադրում հոսքի գրաֆիկական ծանր մասի համար։ Այն թունելում, որը մասնատում կամ գցում է ավելի մեծ տվյալագրամներ, հուսալի ուղին շարունակում է կրել ստեղնաշարի սեղմումները, մինչ գրաֆիկական ուղին կանգ է առնում։ Արդյունքը կպած պատկերի և արձագանքող ստեղնաշարի տարօրինակ համադրությունն է։ Սա նաև բացատրում է, թե ինչու վերամիացումը երբեմն բուժում է ախտանիշը մեկ րոպեով, ապա վերադարձնում այն։

Նստաշրջանը, որը կտրվում և նորից միանում է, այլ խափանում է, իսկ այն, որն ընդհանրապես չի բացվում, երրորդն է։ Ձևը նախ անվանելը խանգարում է սխալ շերտը փորձարկել։

Առանձնացրեք երեք խափանումները երկու հրահանգով

Հասանելիությունը բացառելը էժան է։ Փորձարկեք RDP պորտը հաճախորդից, ապա կարդացեք նստաշրջանի վիճակը հոսթում։

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

Ձախողված TCP թեստը նշանակում է, որ նստաշրջանը երբեք չի բացվել, ուստի դիտարկեք այն որպես ֆայրվոլի, շրջանակի կամ ծառայության խնդիր, այլ ոչ թե սառչել։ Ակտիվ նստաշրջանով հաջող թեստը հաստատում է, որ կառավարման ուղին գոյություն ունի, ինչը հենց սառած պատկերի դեպքն է։ Գործարկեք հոսթի հարցումն այն հաշվից, որն իրավունք ունի տեսնել նստաշրջանները, քանի որ թույլտվության սխալը նման է դատարկ ցանկի։ Գրանցեք նստաշրջանի ID-ն և վիճակը, քանի որ իր ID-ն պահող անջատված նստաշրջանը նույնը չէ, ինչ ակտիվը։

Անջատեք UDP փոխադրումը և համեմատեք

Եթե միայն ցուցասարքն է կանգ առնում, համեմատեք հաճախորդի փոխադրումները մեկ փոփոխությամբ։ Ներկառուցված հաճախորդը և Store հաճախորդը չեն կիսում նույն ստեկը, և ներքևի քաղաքականությունը հեռացնում է UDP-ն ներկառուցված հաճախորդից։

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

1 արժեքը նշանակում է, որ UDP-ն արդեն անջատված է այդ հաճախորդի համար, ուստի կարգավորումը վերապրող սառչելը UDP ուղու խնդիր չէ։ Երբ արժեքը բացակայում է, ակտիվացրեք քաղաքականությունը, նորից միացեք և կրկնեք հենց այն գործողությունը, որը նախկինում սառել էր։ Փորձարկեք Store հաճախորդը որպես առանձին քայլ՝ երկու փոփոխությունները միավորելու փոխարեն, այլապես չեք իմանա, թե որն էր կարևոր։ Պահեք հաճախորդի տարբերակը ձեր նշումներում, քանի որ փոխադրման վարքը փոխվել է Windows-ի թողարկումների ընթացքում։

Երբ մեկ հոսթ սառչում է, իսկ մնացածը լավ են

Այլապես առողջ ենթացանցում միակ խափանված հոսթը ցույց է տալիս թունելից հեռու։ Ստուգեք ուղու MTU-ն և հեռավոր ցուցասարքի ստեկը նախքան VPN կարգավորումներին դիպչելը։

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

Պատասխանը ապացուցում է, որ ուղին կրում է լրիվ չափի փաթեթ առանց մասնատման այդ չափով, մինչդեռ չմասնատելու դրոշով ձախողումը հուշում է, որ թունելի MTU-ն ուշադրություն է պահանջում։ Եթե 1472 բայթ անցնում է և սառչում է միայն այդ հոսթը, նայեք դրա գրաֆիկական վարորդին և ծանրաբեռնվածությանը, ոչ թե ցանցին։ Նույն մեքենային արագ ֆայլի պատճենումը ինչ-որ բան ասում է թողունակության մասին, ոչ թե RDP գրաֆիկական ուղու։ Փոխեք մեկ փոփոխական միաժամանակ և կրկնեք նույն գործողությունը էկրանին, որպեսզի համեմատությունը իմաստ ունենա։

Եթե նստաշրջանն ընդհանրապես չի բացվում, կանգ առեք այստեղ, քանի որ դա հասանելիություն է, ոչ թե սառչել։ Հակառակ դեպքում պահպանեք այն փոխադրման կարգավորումը, որը փոխեց ախտանիշը, և գրանցեք այն հաճախորդի տարբերակի հետ։

Առնչվող հոդվածներ