Always On VPN და VPN On Demand iPhone-ზე: რა განვათავსოთ

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

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

ნაბიჯი 1: დაადგინეთ, რისი იძულება შეუძლია მოწყობილობას

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

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

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

ნაბიჯი 2: წაიკითხეთ on-demand წესები და არა ფუნქციის სახელი

On Demand თანმიმდევრობით შეფასებადი წესების სიაა. ყოველი წესი ასახელებს მოქმედებას და იმ პირობებს, რომლებიც მას ირჩევს, და პირობები საინტერესო ნაწილია: ინტერფეისის ტიპი, Wi-Fi SSID, DNS დომენის სუფიქსი ან შემოწმების URL. წესების ნაკრები, რომელიც არასდროს ემთხვევა, ფუნქციაა, რომელიც არასდროს უკავშირდება.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

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

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

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

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

  • დაუკავშირდით ქსელს, სადაც წესი უნდა დაემთხვეს, შემდეგ მოითხოვეთ პირადი რესურსი და დაადასტურეთ, რომ იტვირთება.
  • გადადით მობილურ ქსელზე აპლიკაციით ფონზე, შემდეგ წამოიყვანეთ იგი წინ და გაიმეორეთ მოთხოვნა.
  • დაუკავშირდით Wi-Fi-ს captive portal-ით და ნახეთ, მისადგომია პორტალი თუ იძულება მას ავტორიზაციამდე ბლოკავს.
  • გამორთეთ გვირაბი ხელით ზედამხედველობის ქვეშ მყოფ მოწყობილობაზე და შეამოწმეთ, თავისით ბრუნდება თუ არა და რამდენად სწრაფად.

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

ნაბიჯი 4: იცოდეთ წარუმატებლობის ორი ფორმა

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

On Demand ფეილდება არგაქტიურებით. წესი არ ემთხვევა, გვირაბი არ ჩნდება, და პირადი რესურსი უბრალოდ ვადას უვადებს. ადვილია ამის არასწორად დიაგნოსტირება სერვერის პრობლემად, რადგან კლიენტი ზუსტად ისე იქცევა, როგორც კონფიგურირებულია.

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

ნაბიჯი 5: გადაამოწმეთ და შემდეგ ივარჯიშეთ უკუქცევაზე

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

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

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

დაკავშირებული სტატიები