რატომ იყინება RDP, როცა დისტანციური კომპიუტერი VPN-ს უკავშირდება

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

ჩაწერეთ ის ბოლო წერტილი, რომელსაც თქვენი სესია რეალურად იყენებს

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

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

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

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

წაიკითხეთ მარშრუტი, რომელიც ამ ბოლო წერტილს პასუხობს

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

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

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

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

თვალი ადევნეთ ფაიერვოლის პროფილის ცვლილებას

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

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

შეადარეთ გვირაბის ინტერფეისზე მიმაგრებული პროფილი იმ პროფილებს, რომლებზეც Remote Desktop-ის წესებია მიმართული. მხოლოდ Domain და Private-სთვის ჩართული წესი არაფერს აკეთებს Public-ად კლასიფიცირებული ინტერფეისისთვის, და ვერც ერთი მარშრუტის შესწორება ვერ შეცვლის ამას. ზოგი VPN კლიენტი დიზაინით ზღუდავს ლოკალურ ქვექსელზე წვდომასაც, რაც იმავე ფორმის მარცხს სხვა მექანიზმიდან იწვევს.

გამოსცადეთ გადასვლა ისეთი ადგილიდან, საიდანაც დაბრუნება შეგიძლიათ

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

დაგეგმეთ უკან დაბრუნება დაწყებამდე, მაგალითად დაგეგმილი ამოცანა, რომელიც rasdial "Work VPN" /disconnect ამუშავებს განსაზღვრული ინტერვალის შემდეგ. ეს დაკარგულ სესიას ხუთწუთიან შეწყვეტად აქცევს ადგილზე ვიზიტის ნაცვლად, და ეს მთელი პროცედურის ყველაზე იაფი დაზღვევაა.

დაბრუნდით შიგნით, როცა სესია უკვე გაქრა

თუ ჰოსტი უკვე მიუწვდომელია, შეწყვიტეთ ახალი RDP კავშირების ცდა იმავე კლიენტიდან და გამოიყენეთ აღდგენის ის არხი, რომელიც გარემოს უკვე აქვს: RD Gateway, ჰიპერვაიზორის კონსოლი ან გარე მართვის ინტერფეისი. სთხოვეთ კონსოლზე წვდომის მქონე ადამიანს, გაუშვას იგივე ბრძანებები Find-NetRoute და Get-NetConnectionProfile, რომ მტკიცებულებები აღდგენას გადაურჩეს.

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