რატომ არ შეუძლია აპს Android-სა თუ iOS-ზე შენახული VPN პროფილის ჩართვა

ორი სრულიად განსხვავებული საქმე პროგრამული VPN-ის სახელქვეით ერთიანდება, და მათგან მხოლოდ ერთია ხელმისაწვდომი ჩვეულებრივი აპისთვის ორივე მობილურ პლატფორმაზე. პირველია იმ პროფილის ჩართვა, რომელიც მომხმარებელმა უკვე შეინახა; მეორეა გვირაბის აშენება საკუთარი პროცესის შიგნით. Android მეორეს VpnService-ის მეშვეობით გაძლევთ, ხოლო iOS მეორეს Network Extension-ის უფლებით, მაშინ როცა პირველი სისტემას, მოწყობილობის მფლობელს ან MDM სერვერს რჩება. იმის გარკვევა, რომელი გჭირდებათ სინამდვილეში, ჩვეულებრივ პროექტს აპატარავებს.

ორი საქმე ერთი სახელით

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

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

Android: თანხმობის კარიბჭე და არავითარი პროფილის API

VpnService არსებობს Android 4.0-დან და აძლევს აპს საშუალებას შექმნას tun ინტერფეისი, შემდეგ წაიკითხოს და ჩაწეროს პაკეტები. სერვისი უნდა გამოცხადდეს BIND_VPN_SERVICE-ით, ხოლო VpnService.prepare() ქმნის სისტემურ დიალოგს, რომელიც მომხმარებელს ნებართვას სთხოვს. პლატფორმის ნიმუში, ToyVpn, განზრახული ფორმის ყველაზე მკაფიო განაცხადია: თქვენი კოდი ფლობს ინტერფეისს და ყველაფერს, რაც მასში გადის.

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

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

iOS: უფლება არის საზღვარი

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

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

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

დესკტოპი უფრო შორს აღწევს, მაგრამ საკუთრება უცვლელია

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

macOS ისევე იქცევა სხვა ინსტრუმენტებთან. scutil --nc start და stop მუშაობს უკვე არსებულ სერვისებზე, მაშინ როცა ერთის შექმნა სისტემური ადმინისტრირების ამოცანაა. პროცესის ფლობა ლეპტოპზე არ გხდით კონფიგურაციის მფლობელს.

რა უნდა ავაშენოთ სამაგიეროდ

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

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