Always On VPN არ არის LAN-წვდომა: რესურსების შემოწმების სია

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

ნაბიჯი 1: ჩაწერეთ რესურსი სანამ შეამოწმებთ

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

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

ჩანაწერი აიძულებს ოთხ ცალკე კითხვას. მარშრუტი წყვეტს სად მიდის მისამართი; DNS პოლიტიკა წყვეტს როგორ შეიტყობს კლიენტი მისამართს; ტრაფიკის ფილტრი წყვეტს შეიძლება თუ არა ამ ტრაფიკმა კავშირის გამოყენება; დანიშნულების firewall და აპლიკაციის ნებართვები წყვეტს მიიღება თუ არა მოთხოვნა. ამ ოთხიდან არც ერთი არ გამომდინარეობს დაკავშირებული გვირაბიდან.

ნაბიჯი 2: განსაზღვრეთ რომელი გვირაბი უნდა ატაროს ის

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

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

ნაბიჯი 3: გადაამოწმეთ მარშრუტი რეალური მისამართისთვის

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

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

ნაბიჯი 4: ცალკე შეამოწმეთ კერძო სახელების გადაწყვეტა

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

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

ნაბიჯი 5: შეამოწმეთ ფილტრები, იდენტობა და აპლიკაციის საკუთარი ჭიშკარი

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

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