RDP-ის გაყინვა VPN-ის გავლით: შეტანა ჯერ კიდევ მუშაობს, ამიტომ შეამოწმეთ ტრანსპორტი

როცა სურათი წყვეტს განახლებას, მაგრამ მაუსი კვლავ სრიალებს დისტანციურ სამუშაო მაგიდაზე, აშკარა დასკვნაა, რომ 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 გრაფიკულ არხზე. შეცვალეთ ერთი ცვლადი ერთდროულად და გაიმეორეთ იგივე მოქმედება ეკრანზე, რომ შედარებას აზრი ჰქონდეს.

თუ სესია საერთოდ არ იხსნება, აქ გაჩერდით, რადგან ეს ხელმისაწვდომობაა და არა გაყინვა. წინააღმდეგ შემთხვევაში შეინარჩუნეთ ის ტრანსპორტის პარამეტრი, რომელმაც სიმპტომი შეცვალა, და ჩაწერეთ იგი კლიენტის ვერსიასთან ერთად.