iOS VPN API: NEVPNManager, გვირაბის მომწოდებელი თუ პროფილი?

სამი განსხვავებული პროდუქტი პასუხობს სახელზე iOS VPN და ისინი არ იზიარებენ ერთ API-ს. Personal VPN სარგებლობს სისტემის ჩაშენებული IPsec და IKEv2 ტრანსპორტებით. Custom tunnel თქვენს საკუთარ პროტოკოლს ატარებს network extension-ის შიგნით. Configuration profile აწყობს რომელიმეს და შეუძლია დაამატოს on-demand ქცევა. ტრანსპორტით არჩევა, რომლითაც უნდა ისაუბროთ, უფრო სწრაფია, ვიდრე იმ გაკვეთილით არჩევა, რომელიც პირველად დაკომპილირდა.

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

ნაბიჯი 1: აირჩიეთ ტრანსპორტით

თუ სერვერი IKEv2 ან Cisco-ის სტილის IPsec-ია, NEVPNManager საკმარისია და სისტემის ტრანსპორტები უფასოდ მოდის. თუ სერვერი ლაპარაკობს OpenVPN, WireGuard ან სხვა რამეს, NEVPNManager ვერ დაეხმარება: მას არ აქვს კაუჭი მესამე მხარის პროტოკოლისთვის. ამ შემთხვევას სჭირდება NETunnelProviderManager packet tunnel provider-ით, რომელიც პროტოკოლს ახორციელებს. პროფილი მხოლოდ კონფიგურაციას ავრცელებს და ვერ დაამატებს ტრანსპორტს, რომელიც ოპერაციულ სისტემას არ აქვს.

PPTP სამიზნე არ არის მიმდინარე სისტემებზე. Shared-secret IPsec ჯერ კიდევ ელოდება ჯგუფის სახელს remoteIdentifier-ში, საიდუმლოს შემნახველ keychain ელემენტს და გაფართოებულ ავთენტიფიკაციას, როცა სერვერი მომხმარებლის სახელს ითხოვს. ყოველი დაკარგული ნაწილი იჩენს თავს როგორც იგივე ზოგადი კონფიგურაციის შეცდომა, ამიტომ დაამატეთ ისინი ყველა, სანამ სხვა რამეს გამართავთ.

ნაბიჯი 2: დაიცავით შენახვის, ჩატვირთვისა და დაწყების რიგი

NEVPNManager წერს preferences-ში, კითხულობს მათ უკან და მხოლოდ ამის შემდეგ იწყებს. შეავსეთ პროტოკოლისა და manager-ის ობიექტები, გამოიძახეთ saveToPreferences, გამოიძახეთ loadFromPreferences და გამოიძახეთ startVPNTunnel load completion handler-იდან. ჩატვირთვის დაბრუნებამდე დაწყება წარმოქმნის configuration-invalid შეცდომას, NEVPNErrorDomain code 1, იმ კონფიგურაციაზე, რომელიც სხვაგვარად სწორია.

ფორმა საკმარისად მოკლეა, რომ ერთ ადგილას შევინახოთ:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

startVPNTunnel ბრუნდება მაშინ, როცა მოთხოვნა მიღებულია, და არა მაშინ, როცა გვირაბი აწეულია. დააკვირდით NEVPNStatusDidChange-ს და წაიკითხეთ connection.status ნამდვილი მდგომარეობისთვის. აპი, რომელიც წარმატებას ვარაუდობს გამოძახების ადგილას, აცხადებს დაკავშირებულ VPN-ს, სანამ extension ჯერ კიდევ მოლაპარაკებას აწარმოებს. Connecting მდგომარეობა ნორმალურია ერთი წუთით; მდგომარეობა, რომელიც არასოდეს ტოვებს მას, არის ის მარცხი, რომლის ლოგირებაც ღირს.

ნაბიჯი 3: მიეცით provider-ის პროცესს ის, რაც სჭირდება

Custom transport მუშაობს ცალკე პროცესში საკუთარი bundle identifier-ითა და საკუთარი entitlement-ით. როგორც container აპს, ისე provider-ს ხელმოწერის დროს სჭირდება network-extension entitlement, და App Store-ის გარეთ Developer ID build მაინც უნდა ატარებდეს მას provisioning profile-ში. დაკარგული entitlement პროტოკოლის ბაგს ჰგავს, რადგან extension უბრალოდ არ იწყებს მუშაობას.

სესხებადი საჯარო socket descriptor არ არსებობს. NEPacketTunnelProvider გაძლევთ NEPacketTunnelFlow-ს read, write და cancel-ით, და კოდი, რომელიც კერძო გასაღების ბილიკებს ეწვდება, ტყდება გამოშვებებს შორის. Provider აგრძელებს მუშაობას, სანამ აპი background-შია, ამიტომ container აპს ამისთვის background რეჟიმი არ სჭირდება.

ნაბიჯი 4: on-demand წესების ნაკრებია, არა გადამრთველი

isOnDemandEnabled მხოლოდ ამზადებს წესებს; NEOnDemandRuleConnect და მისი და-ძმები წყვეტენ, როდის ადის გვირაბი. probe URL-ის მქონე evaluate-connection წესი იმდენად კარგია, რამდენადაც კარგია ეს URL. თუ probe პასუხობს გვირაბის გარეშე, წესი ასკვნის, რომ კერძო ქსელი უკვე მისადგომია და არასოდეს უკავშირდება, ამიტომ მიმართეთ ის რაღაცაზე, რაც მხოლოდ შიგნიდან პასუხობს.

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

ნაბიჯი 5: დაამტკიცეთ გზა და არა ეტიკეტი

tun, tap, ppp ან ipsec ინტერფეისების სკანირება ამტკიცებს, რომ VPN კონფიგურირებულია, და არა რომ თქვენმა მოთხოვნამ გამოიყენა ის. NWPathMonitor usesInterfaceType(.other)-ით ამბობს, რომ ვირტუალური ინტერფეისი ხელმისაწვდომია, და viability handler-ს შეუძლია ერთი ჰოსტის შემოწმება. არც ერთი არ ამტკიცებს გასასვლელ გზას, ამიტომ შეაერთეთ ისინი მოთხოვნასთან რესურსზე, რომელსაც მხოლოდ გვირაბი აღწევს. ინტერფეისების სახელები დიაგნოსტიკური დახმარებაა და არასოდეს კარიბჭე, რომელზეც აპლიკაციის ლოგიკამ უნდა გაანშტოოს.

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