Kāpēc jūsu iOS VPN lietotne rāda atvienotu, lai gan tunelis darbojas
Jūsu iOS lietotne pārvalda tuneli, bet nepieder to, un pārvaldnieka stāvoklis ir kešatmiņā. Vispirms ielādējiet preferences, pēc tam lasiet statusu un saskarnes skaitītājus.
Jūsu lietotne saka atvienots, izvēlnes josla saka savienots, un trafiks acīmredzami plūst. Šī plaisa nav sacensību stāvoklis, ko izlabot ar atkārtotu mēģinājumu: lietotne un tunelis ir atsevišķi procesi, un objekts, ko lasa jūsu kods, ir kešatmiņā saglabāts sistēmas glabātās konfigurācijas skats. Apple Personal VPN virsma ir vadības API, nevis datu ceļš, un lielākā daļa tās dīvainās uzvedības izriet no šī viena fakta. Lūk, kas patiešām notiek katrā izsaukumā.
Pārvaldnieka objekts ir kešatmiņā saglabāts skats, nevis tunelis
NETunnelProviderManager tiek aizpildīts no sistēmas pārvaldītas preferenču krātuves, tāpēc tā īpašības neko nenozīmē, kamēr nav pabeigts loadFromPreferences. Ja pirms tam nolasāt connection.status, iegūstat noklusējuma vērtību, un tāpēc pirmais statusa atjauninājums pēc pārstartēšanas ziņo atvienots, lai gan tunelis darbojas. Vispirms ielādējiet, pēc tam lasiet statusu un protokola konfigurāciju tajā pašā pabeigšanas apstrādātājā. Vēlākās izmaiņas novērojiet ar NEVPNStatusDidChange, nevis aptaujājot, un ņemiet vērā, ka paziņojums nostrādā arī savienojumiem, ko sācis On Demand, kur vispār nav lietotnes izsaukuma, kas varētu kaut ko atgriezt. Tas pats attiecas uz protokola iestatījumiem: tie tiek lasīti no ielādētās konfigurācijas, nevis no tā, ko lietotne nodeva.
Pats tunelis dzīvo Network Extension nodrošinātāja procesā, tāpēc lietotne var zaudēt savu stāvokli, nezaudējot savienojumu. Viss, ko rāda saskarne, ir jāatjauno no pārvaldnieka, nevis jāatceras no iepriekšējās sesijas.
Palaišanas secība: saglabāt, ielādēt, pēc tam palaist
Nodrošinātāja balstītam savienojumam vajadzīgi trīs soļi secībā. Ierakstiet nodrošinātāja konfigurāciju un izsauciet saveToPreferences, ielādējiet pārvaldnieku, lai saglabātā konfigurācija būtu tā, kas jums ir rokā, pēc tam palaidiet ar NETunnelProviderSession.startVPNTunnel(). Ja izlaižat saglabāšanu, palaišanai nav ko palaist; ja ielādējat pirms saglabāšanas, pārvaldnieks joprojām atspoguļo veco konfigurāciju.
startVPNTunnel atgrieztā Būla vērtība tikai pasaka, ka pieprasījums ir pieņemts. Nodrošinātāja līmeņa kļūdas nāk vēlāk kā statusa maiņa uz atvienotu, ko novērojat ar NEVPNStatusDidChange paziņojumu, un paziņojuma apstrādātājam pēc loadFromPreferences ir no jauna jāizlasa connection.status, jo kešatmiņā saglabātā vērtība var būt vēl vecā. Pieprasījuma līmeņa kļūdas atgriežas uzreiz no izsaukuma formas, kas met izņēmumu, vai ar startVPNTunnelAndReturnError: kļūdas izvades parametru. Kods, kas atgriezto vērtību uzskata par rezultātu, ziņo par savienojumu, kas nekad netika izveidots. Otra klusā kļūda ir nodrošinātāja pakotnes identifikators, kas neatbilst instalētajam paplašinājumam: pieprasījums tiek noraidīts, un nekas ziņojumā nenorāda uz identifikatoru. Ja identifikators ir nepareizs, pieprasījums parasti neizdodas uzreiz, pirms parādās jebkura nodrošinātāja žurnāla rinda.
Preferenču atkārtota ielāde pēc palaišanas ir tas, kas padara statusa ekrānus pareizus. Pārvaldnieks jums neiegrūž jaunu konfigurāciju, kad sistēma to maina.
Uzticības materiāls nāk ar profilu, nekad no lietotnes koda
Lietotnei nav atbalstīta veida, kā pievienot saknes sertifikātu iOS uzticības krātuvē, tāpēc Personal VPN konfigurācija var atsaukties tikai uz materiālu, kam ierīce jau uzticas: ķēdi, ko izveidojis instalēts profils, ierīces pārvaldība vai CA, kam sistēma uzticas citu iemeslu dēļ. Lietotne, kas pirmajā palaišanā izveido savu CA un gaida, ka sistēma to atzīs, neizturēs validāciju nodrošinātāja iekšienē, kur lietotnes saskarne nevar redzēt iemeslu.
Uzlūkojiet šo robežu kā tādu dizaina ierobežojumu, kāds tā ir, un piegādājiet uzticības enkuru kopā ar reģistrācijas profilu. Turiet VPN autentifikāciju atsevišķi no uzticības lēmuma, jo tie neizdodas dažādās vietās, un tos atkļūdo dažādi cilvēki.
Skaitītāji nāk no saskarnes, nevis no VPN API
Pārvaldnieks atklāj statusu un konfigurāciju, un neko, kas skaitītu baitus vienam tunelim. Ja vajag lietojuma skaitļus, izsauciet getifaddrs() un nolasiet if_data attiecīgajai saskarnei: en0 Wi-Fi, pdp_ip saskarnes mobilajam tīklam un utun ierīce pašam tunelim. utun skaitītāji raksturo iekšējo trafiku un ietver protokola papildu izmaksas.
Šie skaitļi ir aplēses, nevis uzskaite pa lietotnēm, un tie tiek atiestatīti, kad saskarne tiek izveidota no jauna. Atzīmējiet tos tā saskarnē, citādi kāds tos izmantos klienta rēķinam. Ja vajag skaitļus pa lietotnēm, vajag pavisam citu mehānismu, nevis labāku šo lauku nolasīšanu.
Tīrīšana pieder stopVPNTunnel, nevis pārtraukšanai
applicationWillTerminate dod jums dažas sekundes, pirms sistēma var nogalināt procesu, un tā nav uzticama vieta savienojuma izjaukšanai. Sūtiet apturēšanu uz stopVPNTunnel() vai apstrādājiet to nodrošinātāja apturēšanas atzvanījumā, un saglabājiet pārvaldnieka vai konfigurācijas identifikatoru, ar kuru sākāt, lai apturēšana mērķētu uz šo savienojumu, nevis uz katru ierīces konfigurāciju.
Glabājiet šo identifikatoru blakus profilam, kuram tas pieder, jo pārvaldnieka objekts nefiksē, kuru konfigurāciju lietotājs izvēlējās. Un atcerieties, ka savienojumam, ko paceļ On Demand, vispār nav lietotnes izsaukuma aiz muguras, tāpēc statusa ekrānam joprojām ir jāielādē preferences, pirms tas kaut ko zīmē.