რატომ ვერ რთავს ან თიშავს თქვენი iPhone-ის აპი სისტემურ VPN-ს

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

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

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

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

რა შეუძლია აპს რეალურად შექმნას

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

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

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

მდგომარეობის წაკითხვა იმავე კედელს აწყდება

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

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

On Demand და Always On ნამდვილი ბერკეტებია

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

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

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

გაუშვით მხარდაჭერილი გზა

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

სისტემურ VPN-ს რომ ეხება კერძო API, დემოს გაივლის და მიმოხილვაზე ჩავარდება, ხოლო სხვა გზით თუ გავა, შემდეგ iOS გამოშვებაში გატყდება. ერთი გადამრთველისთვის ამ გაცვლის არც ერთი ვერსია არ ღირს.

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