Wat NEVPNManager op iOS kan skep (en wat nie)

Bou ’n VPN-skerm in ’n iOS-app en die eerste verrassing is dat die protokollys in die Instellings-app nie die API-lys is nie. Die Network Extension-raamwerk laat jou app een persoonlike VPN-konfigurasie skep wat deur daardie app besit word, en dit aanvaar net ’n paar protokolobjekte. Alles anders wat mense verwag, van L2TP tot ’n afgelaaide profiel, lê buite daardie oppervlak of is privaat aan Apple. Die mislukkings wat volg, is gewoonlik nie foute nie; dit is die API wat ’n taak weier wat hy nooit gekry het nie.

Die mite: die API is ’n redigeerder vir Instellings

Die oortuiging is dat omdat iOS IKEv1-, IKEv2-, L2TP- en IPsec-profiele kan opstel, ’n app enigeen daarvan programmaties kan skep. Dit kan nie. Die raamwerk bied presies een konfigurasieslot aan die app wat dit oproep, en daardie slot aanvaar ’n klein stel openbare protokolklasse. Alles anders wat mense verwag, van L2TP tot ’n afgelaaide profiel, lê buite daardie oppervlak of is privaat aan Apple.

Die mislukkings wat volg, is gewoonlik nie foute nie. Dit is die API wat ’n taak weier wat hy nooit gekry het nie, en die oplossing is om die skerm te ontwerp rondom wat die API besit.

Drie protokolobjekte en dié wat nie bestaan nie

Jou opsies is IKEv1 via NEVPNProtocolIPSec, IKEv2 via NEVPNProtocolIKEv2, en NETunnelProviderProtocol as jy jou eie pakkettunneluitbreiding lewer. Die NEVPNManager-verwysing lys die aanvaarde protokolobjekte. L2TP en PPTP verskyn nooit in daardie lys nie, want Apple het geen klasse daarvoor gepubliseer nie. Om een van die twee te probeer, eindig by die stoor met ’n fout, of erger, met ’n konfigurasie wat die stelsel stilweg weier om te gebruik.

Lessenaarkode volg ander reëls. Op macOS stapel SCNetworkInterfaceCreateWithInterface ’n koppelvlaktipes soos L2TP oor IPv4 en heg dit aan ’n netwerkdiens, en networksetup -connectpppoeservice begin die resultaat. Administrateurregte en ’n hulptoepassing is nodig, want die gedeelde geheim en wagwoord gaan in die stelselsleutelbos. Kopieer daardie ontwerp na iOS en niks kompileer nie.

Gee ’n sleutelbosverwysing, nie die wagwoord nie

Nie een van die IKE-klasse aanvaar ’n wagwoord as teks nie. Die twee eienskappe passwordReference en sharedSecretReference wil ’n permanente sleutelbosverwysing hê, wat jy by SecItemCopyMatching kry deur om kSecReturnPersistentRef te vra. Om die itemdata deur te gee, of om ’n string in die veld in te dwing, lewer ’n stoorfout of ’n verbinding met leë geloofsbriewe. Die verwysing is net so duursaam soos die sleutelbositem daaronder, en daarom moet die item bestaan voordat die konfigurasie saamgestel word. Skep dit in dieselfde transaksie as die stoor en jy verwyder ’n hele klas ordeningsfoute.

Sertifikaatverifikasie volg ’n ander roete: identityData plus identityDataPassword vir ’n PKCS#12-blob. Om daardie blob binne die app-pakket te verskeep, is ’n gewoonte uit voorbeeldkode eerder as ’n bekendingsbesluit, want die wagwoord reis saam daarmee en elke kopie van die app dra dieselfde identiteit.

Regtiging en beskikbaarheid bepaal alles

Die bestuurder bestaan dalk glad nie, en die rede is voorsiening. Jou app-identifiseerder het die Network Extension-vermoë saam met die persoonlike VPN-regtiging nodig, en die profiel wat die bou onderteken, moet albei dra.

Slaan dit oor en die gedeelde instansie gee nil terug, of die stoor misluk met ’n fout wat nooit regtiging noem nie. Beskikbaarheid is die ander hek. Teiken enigiets ouer as iOS 8 en die simbool ontbreek by looptyd, so die mislukking is ’n ineenstorting of ’n nil-bestuurder eerder as ’n bestuurder sonder konfigurasie. Kontroleer die looptyd en die regtiging voordat jy jou objekgrafiek ontfout.

Laai, wysig, stoor, en let dan op die op-aanvraag-volgorde

Behandel die lewensiklus as laai, wysig, stoor, en slaan nooit die laai oor nie. Totdat loadFromPreferences klaar is, hou die bestuurder niks en kan die protokolobjek nie gelees of omgeruil word nie.

’n Tweede stoor vervang die konfigurasie in plaas daarvan om nog een by te voeg, so ’n halfvoltooide stoor kan ’n profiel beskadig wat gewerk het. Op-aanvraag-reëls vorm ’n geordende skikking, en daardie volgorde is die beleid. Sit ’n verbind-enige-plek-reël voor die ontkoppelreël en ’n handmatige ontkoppeling word gevolg deur ’n onmiddellike herverbinding, wat soos ’n fout lyk maar die gedokumenteerde evaluering volg.

Skuif die ontkoppelreël na die voorkant wanneer die gebruikersaksie moet wen. Wat buite die app se beheer bly, maak net soveel saak. Roetes kom van die tonnel of die bedienerbeleid eerder as van ’n voorkeur wat jy stel, met ’n pakkettunnelverskaffer wat hulle rapporteer wanneer dit begin. Die app kan nie profiele lys of wysig wat deur ander programme of konfigurasieprofiele geïnstalleer is nie, so moenie ’n skerm belowe wat elke VPN op die toestel wys nie.