API VPN za iOS: NEVPNManager, ponudnik tunela ali profil?

Trije različni izdelki se odzivajo na ime iOS VPN in si ne delijo enega API. Personal VPN uporablja vgrajena transporta IPsec in IKEv2 v sistemu. Custom tunnel izvaja vaš lastni protokol znotraj network extension. Configuration profile konfigurira katerega koli od njiju in lahko doda vedenje on-demand. Izbor po transportu, s katerim se morate pogovarjati, je hitrejši od izbora po tisti vadnici, ki se je prva prevedla.

Zaženite spodnje preglede po vrsti, ker vsak korak predpostavlja, da je prejšnji ustvaril veljavno konfiguracijo.

Korak 1: izberite po transportu

Če je strežnik IKEv2 ali IPsec v slogu Cisco, NEVPNManager zadostuje in sistemski transporti pridejo zastonj. Če strežnik govori OpenVPN, WireGuard ali karkoli drugega, NEVPNManager ne more pomagati: nima kljuke za protokol tretje strani. Ta primer zahteva NETunnelProviderManager s packet tunnel provider, ki izvaja protokol. Profil samo razširja konfiguracijo in ne more dodati transporta, ki ga operacijski sistem nima.

PPTP ni cilj na sedanji sistemih. IPsec s skupno skrivnostjo še vedno pričakuje ime skupine v remoteIdentifier, element keychain s skrivnostjo in razširjeno preverjanje, ko strežnik zahteva uporabniško ime. Vsak manjkajoči del se pokaže kot ista splošna konfiguracijska napaka, zato jih dodajte vse, preden začnete razhroščevati karkoli drugega.

Korak 2: spoštujte vrstni red shranjevanja, nalaganja in zagona

NEVPNManager piše v preferences, jih prebere nazaj in šele nato zažene. Izpolnite objekte protokola in manager, pokličite saveToPreferences, pokličite loadFromPreferences in pokličite startVPNTunnel iz load completion handler. Zagon pred vrnitvijo nalaganja ustvari napako configuration-invalid, NEVPNErrorDomain code 1, na konfiguraciji, ki je sicer pravilna.

Oblika je dovolj kratka, da ostane na enem mestu:

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

startVPNTunnel se vrne, ko je zahteva sprejeta, ne ko je tunel vzpostavljen. Opazujte NEVPNStatusDidChange in berite connection.status za resnično stanje. Aplikacija, ki v mestu klica predpostavlja uspeh, poroča o povezanem VPN, medtem ko extension še vedno pogaja. Stanje connecting je za hip normalno; stanje, iz katerega nikoli ne pride, je okvara, ki se je vredno zabeležiti.

Korak 3: dajte procesu provider tisto, kar potrebuje

Custom transport teče v ločenem procesu z lastnim bundle identifier in lastnim entitlement. Tako container aplikacija kot provider potrebujeta pri podpisu entitlement network-extension, in build Developer ID zunaj App Store ga mora še vedno nositi v provisioning profile. Manjkajoči entitlement je videti kot napaka protokola, ker extension preprosto ne zažene.

Ni javnega socket descriptorja za izposojo. NEPacketTunnelProvider vam da NEPacketTunnelFlow z read, write in cancel, koda, ki sega po poteh zasebnih ključev, pa se med izdajami zlomi. Provider še naprej teče, medtem ko je aplikacija v ozadju, zato container aplikacija za to ne potrebuje načina v ozadju.

Korak 4: on-demand je nabor pravil, ne stikalo

isOnDemandEnabled samo oboroži pravila; NEOnDemandRuleConnect in njegovi bratje odločajo, kdaj se tunel dvigne. Pravilo evaluate-connection s probe URL je vredno toliko, kolikor je vreden ta URL. Če probe odgovori brez tunela, pravilo sklepa, da je zasebno omrežje že dosegljivo, in se nikoli ne poveže, zato ga usmerite na nekaj, kar odgovarja samo od znotraj.

Always-on je ločena obljuba. Potrebuje nadzorovano napravo in upravljano profil, nenadzorovan uporabnik pa lahko profil odstrani kadar koli. Ne pošiljajte zasnove, ki je odvisna od always-on, razen če je flota nadzorovana.

Korak 5: dokažite pot, ne oznake

Skeniranje vmesnikov tun, tap, ppp ali ipsec dokazuje, da je VPN konfiguriran, ne da ga je vaša zahteva uporabila. NWPathMonitor z usesInterfaceType(.other) pravi, da je navidezni vmesnik na voljo, in viability handler lahko preizkusi enega gostitelja. Nobeno ne dokaže izhodne poti, zato ju združite z zahtevo do vira, ki ga doseže samo tunel. Imena vmesnikov so diagnostična pomoč, nikoli vrata, na katerih bi se morala razvejati logika aplikacije.

Za terenski pregled primerjajte javni naslov s tunelom in brez njega ter pridobite samo interno stran. Klic status lahko poroča o povezavi, medtem ko provider pogaja, zato prepustite odločitev izidu vira in status obravnavajte kot podporni dokaz.