Hvad NEVPNManager kan oprette på iOS (og hvad den ikke kan)

Byg en VPN-skærm inde i en iOS-app, og den første overraskelse er, at protokollisten i appen Indstillinger ikke er det samme som API-listen. Network Extension-rammen lader din app oprette én personlig VPN-konfiguration, som ejes af den app, og den accepterer kun nogle få protokolobjekter. Alt andet, folk forventer, fra L2TP til en downloadet profil, ligger uden for den flade eller er Apples private. De fejl, der følger, er normalt ikke fejl; det er API’en, der afviser en opgave, den aldrig har fået.

Myten: API’en er ikke en Indstillings-editor

Troen er, at fordi iOS kan konfigurere IKEv1-, IKEv2-, L2TP- og IPsec-profiler, kan en app oprette enhver af dem programmatisk. Det kan den ikke. Rammen eksponerer præcis én konfigurationsplads til den kaldende app, og den plads accepterer et lille sæt offentlige protokolklasser. Alt andet, folk forventer, fra L2TP til en downloadet profil, ligger uden for den flade eller er Apples private.

De fejl, der følger, er normalt ikke fejl. De er API’en, der afviser en opgave, den aldrig har fået, og løsningen er at designe skærmen omkring det, API’en ejer.

Tre protokolobjekter og dem, der ikke findes

Dine muligheder er IKEv1 via NEVPNProtocolIPSec, IKEv2 via NEVPNProtocolIKEv2 og NETunnelProviderProtocol, hvis du leverer din egen pakketunneludvidelse. NEVPNManager-reference viser de accepterede protokolobjekter. L2TP og PPTP optræder aldrig på den liste, fordi Apple ikke har udgivet nogen klasser til dem. Ethvert forsøg ender ved gemning med en fejl eller, værre, med en konfiguration, som systemet stille afviser at bruge.

Desktopkode følger andre regler. På macOS stabler SCNetworkInterfaceCreateWithInterface en grænsefladetype som L2TP over IPv4 og knytter den til en netværkstjeneste, og networksetup -connectpppoeservice starter resultatet. Der kræves administratorrettigheder og et hjælpeværktøj, fordi den delte hemmelighed og adgangskoden går i systemets nøglering. Kopiér det design til iOS, og intet kompilerer.

Send en nøgleringreference, ikke adgangskoden

Ingen af IKE-klasserne accepterer en adgangskode som tekst. De to egenskaber passwordReference og sharedSecretReference vil have en vedvarende nøgleringreference, som du får fra SecItemCopyMatching ved at bede om kSecReturnPersistentRef. At sende elementets data eller tvinge en streng ind i feltet giver en fejl ved gemning eller en forbindelse med tomme legitimationsoplysninger. Referencen er kun så holdbar som nøgleringselementet bag den, og derfor skal elementet findes, før konfigurationen samles. Opret det i samme transaktion som gemningen, og du fjerner en hel klasse af rækkefølgefejl.

Certifikatautentificering tager en anden vej: identityData plus identityDataPassword for en PKCS#12-blob. At levere den blob inde i app-pakken er en vane fra eksempelkode snarere end en beslutning om udgivelse, fordi adgangskoden rejser med den, og hver kopi af appen bærer den samme identitet.

Berettigelse og tilgængelighed afgør alt

Manageren findes måske slet ikke, og årsagen er provisioning. Din app-identifikator skal have Network Extension-evnen sammen med berettigelsen til personlig VPN, og profilen, der signerer buildet, skal bære begge.

Spring det over, og den delte instans returnerer nil, eller gemningen fejler med en fejl, der aldrig nævner berettigelse. Tilgængelighed er den anden port. Ret dig mod noget ældre end iOS 8, og symbolet mangler ved kørsel, så fejlen er et nedbrud eller en nil-manager frem for en manager uden konfiguration. Kontrollér kørselsmiljøet og berettigelsen, før du fejlretter din objektgraf.

Indlæs, ændr, gem, og hold så øje med rækkefølgen ved behov

Behandl livscyklussen som indlæs, ændr, gem, og spring aldrig indlæsningen over. Indtil loadFromPreferences er færdig, holder manageren intet, og protokolobjektet kan ikke læses eller udskiftes.

En anden gemning erstatter konfigurationen i stedet for at tilføje endnu en, så en halvfærdig gemning kan ødelægge en profil, der virkede. Regler ved behov udgør et ordnet array, og den rækkefølge er politikken. Sæt en forbind-overalt-regel foran afbrydelsesreglen, og en manuel afbrydelse følges af en øjeblikkelig genopkobling, hvilket ligner en defekt, men følger den dokumenterede evaluering.

Flyt afbrydelsesreglen frem, når brugerhandlingen skal vinde. Det, der ligger uden for appens kontrol, betyder lige så meget. Ruter kommer fra tunnelen eller serverpolitikken snarere end fra en præference, du sætter, og en pakketunneludbyder rapporterer dem, når den starter. Appen kan ikke liste eller redigere profiler, der er installeret af andre apps eller konfigurationsprofiler, så lov ikke en skærm, der viser hver VPN på enheden.