VPN-API'er i iOS: NEVPNManager, tunneludbyder eller profil?

Tre forskellige produkter svarer til navnet VPN i iOS, og de deler ikke det samme API. Personlig VPN kører på systemets indbyggede IPsec- og IKEv2-transporter. En brugerdefineret tunnel kører din egen protokol inde i en netværksudvidelse. Og en konfigurationsprofil konfigurerer en af dem og kan tilføje adfærd ved behov. At vælge efter den transport, du skal tale med, er hurtigere end at vælge efter den tutorial, der blev kompileret først.

Kør kontrollerne nedenfor i rækkefølge, fordi hvert trin forudsætter, at det foregående gav en gyldig konfiguration.

Trin 1: vælg efter transport

Hvis serveren er IKEv2 eller Cisco-lignende IPsec, er NEVPNManager nok, og systemets transporter følger gratis med. Hvis serveren taler OpenVPN, WireGuard eller noget andet, kan NEVPNManager ikke hjælpe: den har ingen krog til en tredjepartsprotokol. Det tilfælde kræver NETunnelProviderManager med en pakketunneludbyder, der implementerer protokollen. En profil distribuerer kun konfiguration og kan ikke tilføje en transport, som operativsystemet mangler.

PPTP er ikke et mål på nuværende systemer. IPsec med delt hemmelighed forventer stadig gruppenavnet i remoteIdentifier, et nøgleringselement med hemmeligheden og udvidet godkendelse, når serveren beder om et brugernavn. Hver manglende del viser sig som den samme generiske konfigurationsfejl, så tilføj dem alle, før du fejlfinder noget andet.

Trin 2: respektér rækkefølgen gem, indlæs, start

NEVPNManager skriver til præferencer, læser dem tilbage og starter først derefter. Udfyld protokol- og managerobjekterne, kald saveToPreferences, kald loadFromPreferences, og kald startVPNTunnel fra indlæsningens fuldførelseshandler. Start før indlæsningen vender tilbage giver en fejl om ugyldig konfiguration, kode 1 i NEVPNErrorDomain, på en konfiguration, der ellers er korrekt.

Formen er kort nok til at holde på ét sted:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

startVPNTunnel vender tilbage, når anmodningen er accepteret, ikke når tunnelen er oppe. Observer NEVPNStatusDidChange, og læs connection.status for den reelle tilstand. En app, der antager succes på kaldstedet, rapporterer en tilsluttet VPN, mens udvidelsen stadig forhandler. Status forbinder er normal et øjeblik; en status, der aldrig forlader den, er den fejl, der er værd at logge.

Trin 3: giv udbyderprocessen, hvad den har brug for

En brugerdefineret transport kører i en separat proces med sit eget bundle-id og sin egen rettighed. Både container-appen og udbyderen har brug for netværksudvidelsesrettigheden ved signering, og et Developer ID-build uden for App Store skal stadig bære den i provisioningprofilen. En manglende rettighed ligner en protokolfejl, fordi udvidelsen simpelthen ikke starter.

Der er ingen offentlig socket-deskriptor at låne. NEPacketTunnelProvider giver dig NEPacketTunnelFlow med read, write og cancel, og kode, der rækker efter private nøglestier, brækker mellem udgivelser. Udbyderen kører videre, mens appen er i baggrunden, så container-appen har ikke brug for baggrundstilstand til det.

Trin 4: adfærd ved behov er et regelsæt, ikke en kontakt

isOnDemandEnabled armerer kun reglerne; NEOnDemandRuleConnect og dens søskende afgør, hvornår tunnelen kommer op. En regel om forbindelsesevaluering med en probe-URL er kun så god som den URL. Hvis proben svarer uden tunnelen, konkluderer reglen, at det private netværk allerede er nåeligt, og forbinder aldrig, så peg den på noget, der kun svarer indefra.

Altid-til er et separat løfte. Det kræver en enhed under opsyn og en administreret profil, og en bruger uden opsyn kan fjerne en profil, når det passer dem. Undlad at levere et design, der afhænger af altid-til, medmindre flåden er under opsyn.

Trin 5: bevis vejen, ikke etiketten

At scanne efter tun-, tap-, ppp- eller ipsec-interfaces beviser, at en VPN er konfigureret, ikke at din anmodning brugte den. NWPathMonitor med usesInterfaceType(.other) siger, at et virtuelt interface er tilgængeligt, og en levedygtighedshandler kan teste én vært. Ingen af dem beviser udgangsvejen, så kombiner dem med en anmodning til en ressource, som kun tunnelen kan nå. Interface-navne er en diagnostisk hjælp, aldrig en port, som applikationslogik bør forgrene sig på.

Til et feltcheck skal du sammenligne den offentlige adresse med og uden tunnelen og hente en side, der kun er intern. Et statuskald kan rapportere forbundet, mens udbyderen forhandler, så lad ressourcens resultat afgøre, og behandl status som støttende bevis.