Wêrom dyn iOS VPN-app ûnferbûn toant wylst de tunnel aktyf is

Dyn app seit ûnferbûn, de menubalke seit ferbûn, en it ferkear streamt dúdlik. Dat gat is gjin race condition dy'tsto mei in nije poging oplost: de app en de tunnel binne aparte prosessen, en it objekt dat dyn koade lêst is in cache-e byld fan in konfiguraasje dy't it systeem bewarret. It Personal VPN-flak fan Apple is in kontrôle-API, gjin datapaad, en it measte fan syn frjemde gedrach komt út dat iene feit. Hjir is wat der by elke oprop echt bart.

It behearderobjekt is in cache-e byld, net de tunnel

NETunnelProviderManager wurdt folle út in foarkarren-opslach dy't it systeem besit, dus syn eigenskippen betsjutte neat oant loadFromPreferences klear is. Lês connection.status dêrfoar en do krijst in standertwearde, en dêrom meldt de earste statusferfarsking nei in werstart ûnferbûn wylst de tunnel aktyf is. Laad earst, lês dan de status en de protokolkonfiguraasje út deselde foltôging-behanneler. Observearje lettere feroarings fia NEVPNStatusDidChange ynstee fan te polljen, en merkom dat de notifikaasje ek ôfgiet foar ferbiningen dy't troch On Demand start binne, dêr't hielendal gjin app-oprop bestiet om wat dan ek werom te jaan. Itselsde jildt foar protokolyustellingen: dy wurde lêzen út 'e laden konfiguraasje, net út wat de app trochjûn hat.

De tunnel sels libbet yn in Network Extension-oanbiederproses, dus de app kin syn eigen tastân ferlieze sûnder de ferbining te ferliezen. Alles wat de interface toant moat út 'e behearder wer opboud wurde, net ûnthâlden út 'e lêste sesje.

Startfolchoarder: bewarje, laad, start dan

In oanbieder-basearre ferbining hat trije stappen yn folchoarder needsaak. Skriuw de oanbieder-konfiguraasje en rop saveToPreferences oan, laad de behearder sadat de bewarre konfiguraasje dy is dy'tsto hast, en start dan fia NETunnelProviderSession.startVPNTunnel(). Sla do it bewarjen oer, dan hat de start neat te starten; laadsto foar it bewarjen, dan spegelet de behearder noch de âlde konfiguraasje.

De booleaanske wearde dy't startVPNTunnel weromjout, seit allinnich dat it fersyk akseptearre is. Flatings op oanbiedernivo komme letter as in statusferoaring nei ûnferbûn, dy'tsto fia de notifikaasje NEVPNStatusDidChange observearrest, en de notifikaasje-behanneler moat connection.status op 'e nij lêze nei loadFromPreferences, om't de cache-e wearde noch de âlde wêze kin. Flatings op fersyksnivo komme fuortendaliks werom út 'e goaiende foarm fan 'e oprop, of fia de flater-útparamer fan startVPNTunnelAndReturnError:. Koade dy't de weromjûne wearde as de útkomst behannelet, meldt in ferbining dy't nea ta stân kaam. De oare stille flater is in oanbieder-bondel-identifikaasje dy't net by de ynstalleare ekstinsje past: it fersyk wurdt wegere, en neat yn it berjocht wiist nei de identifikaasje. Is de identifikaasje ferkeard, dan falt it fersyk meast daliks ôf, ear't der in rigel út it oanbieder-log ferskynt.

Foarkarren op 'e nij lade nei in start is wat status-skermen korrekt makket. De behearder skoot dy gjin nije konfiguraasje ta as it systeem dy feroaret.

Fertrouwensmateriaal komt fia profyl, nea út app-koade

In app hat gjin stipe wize om in woartelsertifikaat oan 'e iOS-fertrouwensopslach ta te foegjen, dus in Personal VPN-konfiguraasje kin allinnich materiaal ferwize dêr't it apparaat al op fertrout: in keatling dy't troch in ynstalleare profyl, troch apparaatbehear of troch in CA oanlein is dêr't it systeem om oare redenen op fertrout. In app dy't by de earste start syn eigen CA makket en ferwachtet dat it systeem dy earet, falt ôf by de falidaasje binnen de oanbieder, dêr't de interface fan 'e app de reden net sjen kin.

Besjoch dy grins as de ûntwerpbeheining dy't er is en leverje it fertrouwensanker mei it ynskriuwprofyl. Hâld VPN-autentikaasje skieden fan 'e fertrouwensbeslissing, want se falle op ferskate plakken ôf en wurde troch ferskate minsken debugt.

Tellers komme fan 'e interface, net fan 'e VPN-API

De behearder eksposearret status en konfiguraasje, en neat dat bytes per tunnel telt. Hast gebrûkssifers nedich, rop dan getifaddrs() oan en lês if_data foar de oanbelangjende interface: en0 foar Wi-Fi, de pdp_ip-interfaces foar mobyl en in utun-apparaat foar de tunnel sels. De tellers fan utun beskriuwe yntern ferkear en befetsje protokol-oerhaad.

Dy sifers binne skattings, gjin administraasje per app, en se wurde weromset as de interface op 'e nij makke wurdt. Labelsa se sa yn 'e interface, oars brûkt immen se om in klant te fakturearjen. Hast sifers per app nedich, dan hast in hiel oar meganisme nedich, gjin bettere lêzing fan dizze fjilden.

Opromjen heart by stopVPNTunnel, net by beëiniging

applicationWillTerminate jout dy in pear sekonden foar't it systeem it proses deadzje kin, en dat is gjin betrouber plak om in ferbining ôf te brekken. Stjoer de stop nei stopVPNTunnel() of behannelje dy yn 'e stop-callback fan 'e oanbieder, en hâld de behearder- of konfiguraasje-identifikaasje dy'tsto start bist, sadat de stop dy ferbining rekket ynstee fan elke konfiguraasje op it apparaat.

Bewarje dy identifikaasje njonken it profyl dêr't er by heart, om't in behearderobjekt net fêstleit hokker konfiguraasje de brûker keazen hat. En betink dat in ferbining dy't troch On Demand omheech brocht is hielendal gjin app-oprop efter har hat, dus in status-skerm moat noch altyd foarkarren lade foar't it wat tekenet.