Hva NEVPNManager kan lage på iOS (og hva det ikke kan)

Når du bygger en VPN-skjerm inne i en iOS-app, er den første overraskelsen at protokollisten i Innstillinger-appen ikke er API-listen. Network Extension-rammeverket lar appen din lage én personlig VPN-konfigurasjon, eid av den appen, og den godtar bare noen få protokollobjekter. Alt annet folk forventer, fra L2TP til en nedlastet profil, ligger utenfor denne flaten eller er Apples private. Feilene som følger er vanligvis ikke feil, det er API-et som nekter en jobb det aldri fikk.

Myten: API-et er en Innstillinger-redigering

Man tror at fordi iOS kan konfigurere IKEv1-, IKEv2-, L2TP- og IPsec-profiler, kan en app lage hvilken som helst av dem programmatisk. Det kan den ikke. Rammeverket eksponerer nøyaktig én konfigurasjonsplass for appen som kaller, og den plassen godtar bare et lite sett offentlige protokollklasser. Alt annet folk forventer, fra L2TP til en nedlastet profil, ligger utenfor denne flaten eller er Apples private.

Feilene som følger er vanligvis ikke feil. Det er API-et som nekter en jobb det aldri fikk, og løsningen er å utforme skjermen rundt det API-et eier.

Tre protokollobjekter og de som ikke finnes

Valgene dine er IKEv1 via NEVPNProtocolIPSec, IKEv2 via NEVPNProtocolIKEv2, og NETunnelProviderProtocol hvis du leverer din egen pakketunnelutvidelse. NEVPNManager-referansen lister opp de godtatte protokollobjektene. L2TP og PPTP vises aldri i den listen fordi Apple ikke publiserte klasser for dem. Å prøve en av dem ender ved lagring med en feil, eller verre, med en konfigurasjon systemet stille nekter å bruke.

Skrivebordskode følger andre regler. På macOS stabler SCNetworkInterfaceCreateWithInterface en grensesnitttype som L2TP over IPv4 og knytter den til en nettverkstjeneste, og networksetup -connectpppoeservice starter resultatet. Administratorrettigheter og et hjelpeverktøy kreves, siden den delte hemmeligheten og passordet går inn i systemnøkkelringen. Kopier det designet til iOS, og ingenting kompileres.

Send en nøkkelringreferanse, ikke passordet

Ingen av de to IKE-klassene godtar et passord som tekst. De to egenskapene passwordReference og sharedSecretReference vil ha en vedvarende nøkkelringreferanse, som du får fra SecItemCopyMatching ved å be om kSecReturnPersistentRef. Å sende elementdataene, eller å presse en streng inn i feltet, gir en lagringsfeil eller en tilkobling med tomme påloggingsdata. Referansen er bare så varig som nøkkelringselementet bak den, og derfor må elementet finnes før konfigurasjonen settes sammen. Lag det i samme transaksjon som lagringen, og du fjerner en hel klasse rekkefølgefeil.

Sertifikatautentisering tar en annen rute: identityData pluss identityDataPassword for en PKCS#12-blob. Å levere den bloben i app-pakken er en vane arvet fra eksempelkoden, ikke en utgivelsesbeslutning, fordi passordet reiser med den og hver kopi av appen bærer samme identitet.

Rettighet og tilgjengelighet portvokter alt

Behandleren finnes kanskje ikke i det hele tatt, og årsaken er provisjonering. App-identifikatoren din trenger Network Extension-evnen sammen med rettigheten for personlig VPN, og profilen som signerer bygget må bære begge.

Hopp over det, og den delte instansen returnerer nil, eller lagringen mislykkes med en feil som aldri nevner rettigheten. Tilgjengelighet er den andre porten. Retter du deg mot noe eldre enn iOS 8, mangler symbolet ved kjøring, så feilen er et krasj eller en nil-behandler, ikke en behandler uten konfigurasjon. Sjekk kjøretiden og rettigheten før du feilsøker objektgrafen din.

Last, endre, lagre, og se deretter på rekkefølgen ved forespørsel

Behandle livssyklusen som last, endre, lagre, og hopp aldri over lastingen. Til loadFromPreferences er fullført, holder behandleren ingenting, og protokollobjektet kan ikke leses eller byttes.

En ny lagring erstatter konfigurasjonen i stedet for å legge til en annen, så en halvferdig lagring kan skade en profil som virket. Regler ved forespørsel danner en ordnet matrise, og den rekkefølgen er policyen. Sett en koble-til-overalt-regel foran frakoblingsregelen, og en manuell frakobling følges av umiddelbar gjentilkobling, noe som ser ut som en defekt men følger den dokumenterte vurderingen.

Flytt frakoblingsregelen frem når brukerhandlingen må vinne. Det som ligger utenfor appens kontroll betyr like mye. Ruter kommer fra tunnelen eller serverpolicyen i stedet for fra en innstilling du setter, og en pakketunnelleverandør rapporterer dem når den starter. Appen kan ikke liste eller redigere profiler installert av andre apper eller konfigurasjonsprofiler, så ikke lov en skjerm som viser hver VPN på enheten.