Cisco Secure Client RDP სესიიდან VPN-ს ბლოკავს

შესვლა წარმატებით სრულდება და გვირაბი მაინც არ ადის. ეს კომბინაცია აბნევს ადამიანებს, რადგან კითხულობენ როგორც ავთენტიფიკაციის პრობლემას და შემდეგ ნახევარ დღეს ხარჯავენ იმ მონაცემების განულებაზე, რომლებიც არასდროს ყოფილა მიზეზი. Cisco Secure Client-ს შეუძლია უარი თქვას VPN-ის დამყარებაზე სწორედ იმიტომ, რომ მცდელობა Remote Desktop სესიიდან მოვიდა, და ამ გადაწყვეტილებას კლიენტის მხარეს პოლიტიკა იღებს.

სად ჩნდება ეს კავშირის პროცესში

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

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

პარამეტრი, რომელიც რეალურად წყვეტს

Windows VPN Establishment პოლიტიკა შესაბამისი კონტროლია და მას ორი დოკუმენტირებული მნიშვნელობა აქვს: მხოლოდ ლოკალური მომხმარებლები და დისტანციური მომხმარებლების დაშვება. მეორე საშუალებას აძლევს გვირაბი აშენდეს Remote Desktop სესიიდან მხარდაჭერილ კონფიგურაციაში. პირველი ნაგულისხმევი პოზიციაა ბევრ კორპორატიულ პროფილში.

არ აურიოთ Windows Logon Enforcement-თან, რომელსაც პროფილის გზამკვლევი ცალკე პოლიტიკად აღწერს შესვლის სესიებზე. ერთი აწესრიგებს, რომელ სესიას შეუძლია გვირაბის აშენება, მეორე აწესრიგებს ერთდროულ ან შესვლამდე ქცევას. არასწორის შეცვლა ხილულ ეფექტს არ იძლევა.

წაიკითხეთ პროფილი, რომელიც რეალურად გამოიყენება

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

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

RDP გზა გვირაბის ასვლის შემდეგ

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

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

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

რა გაუგზავნოთ ადმინისტრატორს

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

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

გადაამოწმეთ დამტკიცებული ცვლილების შემდეგ

პროფილის განახლების შემდეგ დაამყარეთ ახალი RDP სესია და ხელახლა დაუკავშირდით, შემდეგ განზრახ გაიარეთ გათიშვის თანმიმდევრობა. დაადასტურეთ, რომ გვირაბი ადის, მართვის გზა რჩება და თქვენს ანგარიშს კვლავ შეუძლია სამუშაო მაგიდაზე შესვლა.

VPN-ში დაშვება, სესიის გადარჩენა და Windows-ში შესვლის უფლება სამი ცალკე შემოწმებაა. ერთის გავლა არაფერს ამბობს დანარჩენ ორზე.