Mga API ng VPN para sa iOS: NEVPNManager, tagapagbigay ng tunnel o profile?

Tatlong magkakaibang produkto ang tumutugon sa pangalang iOS VPN, at hindi sila nagbabahagi ng isang API. Personal VPN ay sumasakay sa built-in na IPsec at IKEv2 transports ng system. Custom tunnel ay nagpapatakbo ng sarili mong protocol sa loob ng network extension. Configuration profile ay nagko-configure ng alinman sa dalawa at maaaring magdagdag ng on-demand na pag-uugali. Mas mabilis ang pagpili ayon sa transport na kailangan mong kausapin kaysa sa pagpili ayon sa tutorial na unang na-compile.

Patakbuhin ang mga pagsusuri sa ibaba nang sunod-sunod, dahil ipinapalagay ng bawat hakbang na ang nauna ay gumawa ng valid na configuration.

Hakbang 1: pumili ayon sa transport

Kung ang server ay IKEv2 o IPsec sa istilong Cisco, sapat na ang NEVPNManager at libreng kasama ang system transports. Kung ang server ay nagsasalita ng OpenVPN, WireGuard o anupamang iba, hindi makakatulong ang NEVPNManager: wala itong hook para sa third-party protocol. Ang kasong iyon ay nangangailangan ng NETunnelProviderManager kasama ang packet tunnel provider na nagpapatupad ng protocol. Ang profile ay namamahagi lamang ng configuration, at hindi ito makakapagdagdag ng transport na wala sa operating system.

Ang PPTP ay hindi target sa kasalukuyang mga system. Ang IPsec na may shared secret ay umaasa pa rin sa pangalan ng grupo sa remoteIdentifier, isang keychain item na may hawak ng secret, at extended authentication kapag humihingi ng username ang server. Bawat nawawalang piraso ay lumalabas bilang parehong generic na error sa configuration, kaya idagdag silang lahat bago mag-debug ng iba pa.

Hakbang 2: igalang ang pagkakasunod-sunod na save, load, start

Ang NEVPNManager ay nagsusulat sa preferences, binabasa ito pabalik, at saka lang nagsisimula. Punan ang protocol at manager objects, tawagin ang saveToPreferences, tawagin ang loadFromPreferences, at tawagin ang startVPNTunnel mula sa load completion handler. Ang pagsisimula bago bumalik ang load ay gumagawa ng configuration-invalid error, NEVPNErrorDomain code 1, sa configuration na kung hindi ay tama.

Ang hugis ay sapat na maikli upang itago sa isang lugar:

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

Bumabalik ang startVPNTunnel kapag tinanggap ang request, hindi kapag nakataas na ang tunnel. Obserbahan ang NEVPNStatusDidChange at basahin ang connection.status para sa tunay na estado. Ang app na ipinapalagay ang tagumpay sa call site ay nag-uulat ng konektadong VPN habang nakikipag-usap pa ang extension. Ang connecting status ay normal sandali; ang status na hindi kailanman lumalabas dito ang failure na sulit i-log.

Hakbang 3: bigyan ang provider process ng kailangan nito

Ang Custom transport ay tumatakbo sa hiwalay na process na may sariling bundle identifier at sariling entitlement. Parehong kailangan ng container app at ng provider ang network-extension entitlement sa oras ng pag-sign, at ang Developer ID build sa labas ng App Store ay dapat pa ring magdala nito sa provisioning profile. Ang nawawalang entitlement ay mukhang protocol bug dahil hindi lang nagsisimula ang extension.

Walang pampublikong socket descriptor na mahihiram. Ang NEPacketTunnelProvider ay nagbibigay sa iyo ng NEPacketTunnelFlow na may read, write at cancel, at ang code na umaabot sa private key paths ay nasisira sa pagitan ng mga release. Patuloy na tumatakbo ang provider habang nasa background ang app, kaya hindi kailangan ng container app ang background mode para doon.

Hakbang 4: ang on-demand ay isang set ng patakaran, hindi switch

Ang isOnDemandEnabled ay nag-aarmas lamang ng mga patakaran; ang NEOnDemandRuleConnect at mga kapatid nito ang nagpapasya kung kailan aakyat ang tunnel. Ang evaluate-connection rule na may probe URL ay kasinghusay lamang ng URL na iyon. Kung sumagot ang probe nang walang tunnel, ipinapasiya ng patakaran na naaabot na ang private network at hindi na kailanman kumokonekta, kaya itutok ito sa isang bagay na sumasagot lamang mula sa loob.

Ang Always-on ay hiwalay na pangako. Nangangailangan ito ng pinangangasiwaang device at pinamamahalaang profile, at ang hindi pinangangasiwaang user ay maaaring magtanggal ng profile kahit kailan. Huwag magpadala ng disenyong umaasa sa always-on maliban kung pinangangasiwaan ang fleet.

Hakbang 5: patunayan ang landas, hindi ang label

Ang pag-scan para sa tun, tap, ppp o ipsec interfaces ay nagpapatunay na naka-configure ang isang VPN, hindi na ginamit ito ng iyong request. Ang NWPathMonitor na may usesInterfaceType(.other) ay nagsasabi na may available na virtual interface, at ang viability handler ay makapagpapatunay ng isang host. Wala sa dalawa ang nagpapatunay ng exit path, kaya pagsamahin sila sa isang request sa resource na tanging ang tunnel ang makakaabot. Ang mga pangalan ng interface ay diagnostic aid, hindi kailanman gate na dapat pagsanga-sangahan ng app logic.

Para sa field check, ihambing ang public address na may at walang tunnel at kunin ang internal-only na pahina. Ang status call ay maaaring mag-ulat ng konektado habang nakikipag-usap ang provider, kaya hayaan ang resulta ng resource ang magpasya at ituring ang status bilang sumusuportang ebidensya.