ორი iPhone VPN ერთდროულად: რომელი ატარებს თქვენს ტრაფიკს?

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

მითი: ორი დაკავშირებული VPN ჯაჭვია

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

თუ ბუდობა გჭირდებათ, დააპროექტეთ ის ბუდობად. ნუ გამოიტანთ მას ორი კავშირის ინდიკატორიდან. ეს განსხვავება ბევრ გამართვას ზოგავს.

ამ მითის უკან მდგარი დოკუმენტირებული მოდელი

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

აქ Personal VPN არის API ტერმინი NEVPNManager-ით მართული ჩაშენებული IPsec ან IKEv2 იმპლემენტაციისთვის. NETunnelProviderManager არის გვირაბის პროვაიდერის მოდელი. მომხმარებლის აპს შეუძლია გამოიყენოს პროვაიდერის მოდელი, ამიტომ personal-ის შემცველი პროდუქტის სახელი მას არ აკლასიფიცირებს.

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

მითი: პირადი VPN იღებს დათვალიერების ტრაფიკს

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

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

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

მარშრუტის პრიორიტეტი გაყოფილი გვირაბის სამუშაო პროფილით

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

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

ჩაწერეთ ორი ნაკადი და შეამოწმეთ თითოეული

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

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