VPN-API en iOS: NEVPNManager, tunela provizanto aŭ profilo?

Tri malsamaj produktoj respondas al la nomo VPN en iOS, kaj ili ne dividas unu API. Persona VPN iras sur la sistemaj enkonstruitaj transportoj IPsec kaj IKEv2. Propra tunelo rulas vian propran protokolon ene de reta etendaĵo. Kaj agorda profilo agordas ĉiun el la du kaj povas aldoni konduton laŭpete. Elekti laŭ la transporto, kun kiu vi devas paroli, estas pli rapida ol elekti laŭ tiu lernilo, kiu unue kompiliĝis.

Plenumu la subajn kontrolojn laŭorde, ĉar ĉiu paŝo supozas, ke la antaŭa produktis validan agordon.

Paŝo 1: elektu laŭ transporto

Se la servilo estas IKEv2 aŭ IPsec laŭ la stilo de Cisco, NEVPNManager sufiĉas kaj la sistemaj transportoj venas senpage. Se la servilo parolas OpenVPN, WireGuard aŭ ion alian, NEVPNManager ne povas helpi: ĝi havas neniun hokon por protokolo de tria partio. Tiu kazo bezonas NETunnelProviderManager kun paketa tunela provizanto, kiu efektivigas la protokolon. Profilo nur disdonas agordon kaj ne povas aldoni transporton, kiun la operaciumo ne havas.

PPTP ne estas celo sur nunaj sistemoj. IPsec kun komuna sekreto ankoraŭ atendas la grupan nomon en remoteIdentifier, ŝlosilĉenan eron tenantan la sekreton, kaj etenditan aŭtentigon kiam la servilo petas uzantnomon. Ĉiu mankanta peco montriĝas kiel la sama ĝenerala agorda eraro, do aldonu ilin ĉiujn antaŭ ol sencimigi ion alian.

Paŝo 2: respektu la ordon konservi, ŝargi, startigi

NEVPNManager skribas al agordoj, relegas ilin kaj nur poste startigas. Plenigu la protokolajn kaj administrajn objektojn, voku saveToPreferences, voku loadFromPreferences, kaj voku startVPNTunnel el la fina traktilo de la ŝargo. Starti antaŭ ol la ŝargo revenas produktas eraron pri malvalida agordo, kodo 1 en NEVPNErrorDomain, ĉe agordo, kiu alie estas ĝusta.

La formo estas sufiĉe mallonga por teni ĝin en unu loko:

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

startVPNTunnel revenas kiam la peto estas akceptita, ne kiam la tunelo estas supre. Observu NEVPNStatusDidChange kaj legu connection.status por la reala stato. Aplikaĵo, kiu supozas sukceson ĉe la vokloko, raportas konektitan VPN dum la etendaĵo ankoraŭ intertraktas. Stato de konektado estas normala por momento; stato, kiu neniam forlasas ĝin, estas la paneo inda je registro.

Paŝo 3: donu al la provizanta procezo tion, kion ĝi bezonas

Propra transporto rulas en aparta procezo kun propra pakaĵa identigilo kaj propra rajtigo. Kaj la ujuma aplikaĵo kaj la provizanto bezonas la retetan etendan rajtigon ĉe subskribo, kaj konstruo kun Developer ID ekster App Store ankoraŭ devas porti ĝin en la proviza profilo. Mankanta rajtigo aspektas kiel protokola cimo, ĉar la etendaĵo simple ne startas.

Ne ekzistas publika inga priskribilo por prunti. NEPacketTunnelProvider donas al vi NEPacketTunnelFlow kun read, write kaj cancel, kaj kodo, kiu etendiĝas al privataj ŝlosilaj vojoj, rompiĝas inter eldonoj. La provizanto daŭre rulas dum la aplikaĵo estas fone, do la ujo bezonas neniun fonan reĝimon por tio.

Paŝo 4: laŭpete estas regularo, ne ŝaltilo

isOnDemandEnabled nur armas la regulojn; NEOnDemandRuleConnect kaj ĝiaj gefratoj decidas kiam la tunelo leviĝas. Regulo pri takso de konekto kun prova URL valoras tiom, kiom tiu URL. Se la provo respondas sen la tunelo, la regulo konkludas, ke la privata reto jam atingeblas, kaj neniam konektiĝas, do direktu ĝin al io, kio respondas nur de interne.

Ĉiam-aktiva estas aparta promeso. Ĝi bezonas observatan aparaton kaj administritan profilon, kaj neobservata uzanto povas forigi profilon kiam ajn ĝi volas. Ne sendu dezajnon dependan de ĉiam-aktiva krom se la aparataro estas observata.

Paŝo 5: pruvu la vojon, ne la etikedon

Skani por tun, tap, ppp aŭ ipsec-interfacoj pruvas, ke VPN estas agordita, ne ke via peto uzis ĝin. NWPathMonitor kun usesInterfaceType(.other) diras, ke virtuala interfaco disponeblas, kaj vivkapabla traktilo povas testi unu gastiganton. Neniun el la du pruvas la elirvojon, do kombinu ilin kun peto al rimedo, kiun nur la tunelo povas atingi. Interfacaj nomoj estas diagnoza helpo, neniam pordego, sur kiu aplika logiko devus branĉiĝi.

Por kampokontrolo, komparu la publikan adreson kun kaj sen la tunelo kaj alportu paĝon nur internan. Statusa voko povas raporti konektitan dum la provizanto intertraktas, do lasu la rimedan rezulton decidi kaj traktu la statuson kiel subtenan pruvon.