Firwat deng iOS VPN-App „getrennt“ weist, obwuel den Tunnel leeft

Deng App seet getrennt, d'Menüleescht seet verbonnen, an den Traffic fléisst kloer. Dës Lück ass keng Race Condition, déi s du mat engem Retry flécks: d'App an den Tunnel sinn getrennt Prozesser, an dat Objet, wat däin Code liest, ass eng am Cache gespäichert Vue vun enger Konfiguratioun, déi de System späichert. D'Personal-VPN-Uewerfläch vun Apple ass eng Kontroll-API, keen Datenwee, an de gréissten Deel vun hirem komeschen Verhalen kënnt aus dëser eenzeger Tatsaach. Hei ass, wat bei all Opruff wierklech passéiert.

D'Manager-Objet ass eng am Cache gespäichert Vue, net den Tunnel

NETunnelProviderManager gëtt aus engem Preferences-Store gefëllt, deen de System besëtzt, also bedeiten seng Eegenschaften näischt, bis loadFromPreferences fäerdeg ass. Liest s du connection.status virdru, kris du en Default-Wäert, an dofir mellt deen éischte Status-Refresh no engem Neistart getrennt, obwuel den Tunnel leeft. Lued fir d'éischt, da lies de Status an d'Protokollkonfiguratioun aus demselwe Completion-Handler. Beobachte spéider Ännerungen iwwer NEVPNStatusDidChange amplaz ze poll, a bemierk, datt d'Notifikatioun och fir Verbindungen ausgeléist gëtt, déi vun On Demand gestart goufen, wou et guer keen App-Opruff gëtt, dee kéint eppes zréckginn. Datselwecht gëllt fir Protokollastellungen: si ginn aus der geluedener Konfiguratioun gelies, net aus deem, wat d'App iwwerginn huet.

Den Tunnel selwer lieft an engem Network-Extension-Provider-Prozess, also kann d'App hireen eegenen Zoustand verléieren, ouni d'Verbindung ze verléieren. Alles, wat d'Interface weist, muss aus dem Manager nei opgebaut ginn, net aus der leschter Sessioun erënnert.

Startreihenfolg: späicheren, lueden, da starten

Eng providerbaséiert Verbindung brauch dräi Schrëtt an der Reihenfolg. Schreib d'Provider-Konfiguratioun a ruff saveToPreferences op, lued de Manager, sou datt déi gespäichert Konfiguratioun déi ass, déi s du an der Hand hues, a start da iwwer NETunnelProviderSession.startVPNTunnel(). Wa s d'Späicheren iwwerspréngs, huet den Start näischt ze starten; wa s virum Späichere lueds, spigelt de Manager nach déi al Konfiguratioun.

De boolesche Wäert, deen startVPNTunnel zréckgëtt, seet just, datt d'Ufro ugeholl gouf. Feeler op Provider-Niveau komme méi spéit als Statusännerung op getrennt, déi s du iwwer d'Notifikatioun NEVPNStatusDidChange observéiers, an den Notifikatiouns-Handler muss connection.status no loadFromPreferences nach eng Kéier liesen, well de am Cache gespäicherte Wäert nach deenen ale ka sinn. Feeler op Ufro-Niveau komme gläich zeréck aus der werfender Form vum Opruff oder iwwer de Feeler-Ausgabsparameter vun startVPNTunnelAndReturnError:. Code, deen de Retourwäert als Resultat behandelt, mellt eng Verbindung, déi ni opgebaut gouf. Den anere stille Feeler ass eng Provider-Bundle-Identifizéierung, déi net zur installéierter Extensioun passt: d'Ufro gëtt ofgewisen, an näischt an der Meldung weist op d'Identifizéierung. Ass d'Identifizéierung falsch, schléit d'Ufro meeschtens direkt fehl, ier eng eenzeg Logzeil vum Provider erschéngt.

D'Preferences no engem Start nei ze lueden ass dat, wat Statuswierfer richteg mécht. De Manager dréckt der keng nei Konfiguratioun op, wann de System se ännert.

Vertrauensmaterial kënnt iwwer Profil, ni aus App-Code

Eng App huet keen ënnerstëtzten Wee, en Root-Zertifikat an den iOS-Vertrauensstore ze setzen, also kann eng Personal-VPN-Konfiguratioun nëmme Material referenzéieren, deem den Apparat schonn vertraut: eng Kette, déi duerch e installéiert Profil, duerch Geräteverwaltung oder duerch eng CA opgebaut gouf, déi de System aus anere Grënn vertraut. Eng App, déi beim éischte Start hir eege CA erstellt an erwaart, datt de System se unerkennt, wäert d'Validéierung am Provider scheiteren, wou d'Interface vun der App de Grond net ka gesinn.

Betruecht dës Grenz als déi Designrestriktioun, déi se ass, a leet den Vertrauensanker mam Inscriptiounsprofil aus. Halt d'VPN-Authentifikatioun getrennt vun der Vertrauensentscheedung, well se op verschiddenen Plazen scheiteren a vu verschiddene Leit gedebuggt ginn.

Zieler kommen aus der Interface, net aus der VPN-API

De Manager exposéiert Status a Konfiguratioun an näischt, wat Bytes pro Tunnel zielt. Brauchs du Notzungszuelen, ruff getifaddrs() op a lies if_data fir déi entspriechend Interface: en0 fir Wi-Fi, d'pdp_ip-Interfacen fir Mobilfunk an en utun-Apparat fir den Tunnel selwer. D'Zieler vun utun beschreiwen den bannenzege Traffic a enthalen den Overhead vum Protokoll.

Dës Zuelen sinn Schätzungen, keng Ofrechnung pro App, an se ginn zréckgesat, wann d'Interface nei erstallt gëtt. Etikettéier se sou an der Interface, soss benotzt een se, fir engem Client eng Rechnung ze stellen. Brauchs du Zuelen pro App, brauchs du eng ganz aner Mechanismus, net eng besser Liesung vun dëse Felder.

D'Botzen gehéiert an stopVPNTunnel, net an d'Terminatioun

applicationWillTerminate gëtt der e puer Sekonnen, ier de System de Prozess ka killen, an dat ass kee verléisslechen Ort, fir eng Verbindung ofzebauen. Schéck de Stop un stopVPNTunnel() oder behännel en am Stop-Callback vum Provider, a behalt d'Manager- oder Konfiguratiouns-Identifizéierung, mat där s du gestart hues, sou datt de Stop déi Verbindung trëfft amplaz all Konfiguratioun um Apparat.

Späicher déi Identifizéierung nieft dem Profil, zu deem se gehéiert, well en Manager-Objet net festhält, wéi eng Konfiguratioun de Benotzer gewielt huet. A vergiess net, datt eng Verbindung, déi vun On Demand opbruecht gëtt, guer keen App-Opruff hannendrun huet, also muss en Statuswierfer nach ëmmer d'Preferences lueden, ier en eppes zeechent.