iOS VPN API: NEVPNManager, tuneļa nodrošinātājs vai profils?

Trīs dažādi produkti atbild uz iOS VPN nosaukumu, un tie nedala vienu API. Personal VPN izmanto sistēmas iebūvētos IPsec un IKEv2 transportus. Custom tunnel darbina jūsu pašu protokolu network extension iekšienē. Configuration profile konfigurē jebkuru no tiem un var pievienot on-demand uzvedību. Izvēlēties pēc transporta, ar kuru jums jārunā, ir ātrāk nekā izvēlēties pēc tās apmācības, kas tika kompilēta pirmā.

Veiciet zemāk esošās pārbaudes secīgi, jo katrs solis pieņem, ka iepriekšējais radīja derīgu konfigurāciju.

1. solis: izvēlieties pēc transporta

Ja serveris ir IKEv2 vai Cisco stila IPsec, ar NEVPNManager pietiek un sistēmas transporti nāk par brīvu. Ja serveris runā OpenVPN, WireGuard vai ko citu, NEVPNManager nevar palīdzēt: tam nav āķa trešās puses protokolam. Šajā gadījumā vajag NETunnelProviderManager ar packet tunnel provider, kas ievieš protokolu. Profils tikai izplata konfigurāciju, un tas nevar pievienot transportu, kura operētājsistēmai nav.

PPTP nav mērķis pašreizējās sistēmās. Shared-secret IPsec joprojām gaida grupas nosaukumu remoteIdentifier, keychain vienumu ar noslēpumu un paplašinātu autentifikāciju, kad serveris prasa lietotājvārdu. Katrs trūkstošais gabals parādās kā tā pati vispārīgā konfigurācijas kļūda, tāpēc pievienojiet tos visus, pirms atkļūdojat ko citu.

2. solis: ievērojiet saglabāšanas, ielādes un palaišanas kārtību

NEVPNManager raksta preferences, nolasa tos atpakaļ un tikai tad palaiž. Aizpildiet protokola un manager objektus, izsauciet saveToPreferences, izsauciet loadFromPreferences un izsauciet startVPNTunnel no load completion handler. Palaišana pirms ielādes atgriešanās rada configuration-invalid kļūdu, NEVPNErrorDomain code 1, konfigurācijā, kas citādi ir pareiza.

Forma ir pietiekami īsa, lai to turētu vienā vietā:

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

startVPNTunnel atgriežas, kad pieprasījums ir pieņemts, nevis kad tunelis ir uzcelts. Novērojiet NEVPNStatusDidChange un lasiet connection.status īstajam stāvoklim. Lietotne, kas pieņem panākumus izsaukuma vietā, ziņo par savienotu VPN, kamēr extension vēl pārrunā. Connecting stāvoklis uz mirkli ir normāls; stāvoklis, kas no tā nekad neiziet, ir kļūme, ko ir vērts reģistrēt.

3. solis: dodiet provider procesam to, kas tam vajadzīgs

Custom transport darbojas atsevišķā procesā ar savu bundle identifier un savu entitlement. Gan container lietotnei, gan provider parakstīšanas laikā vajag network-extension entitlement, un Developer ID build ārpus App Store joprojām to nes provisioning profile. Trūkstošs entitlement izskatās kā protokola kļūda, jo extension vienkārši nepalaižas.

Nav publiska socket descriptor, ko aizņemties. NEPacketTunnelProvider dod jums NEPacketTunnelFlow ar read, write un cancel, un kods, kas tiecas uz privāto atslēgu ceļiem, salūzt starp laidieniem. Provider turpina darboties, kamēr lietotne ir fonā, tāpēc container lietotnei tam nav vajadzīgs fona režīms.

4. solis: on-demand ir noteikumu kopums, nevis slēdzis

isOnDemandEnabled tikai uzmodina noteikumus; NEOnDemandRuleConnect un tā brāļi izlemj, kad tunelis ceļas. evaluate-connection noteikums ar probe URL ir tik labs, cik labs ir šis URL. Ja probe atbild bez tuneļa, noteikums secina, ka privātais tīkls jau ir sasniedzams, un nekad nepievienojas, tāpēc vērsiet to uz kaut ko, kas atbild tikai no iekšpuses.

Always-on ir atsevišķs solījums. Tam vajag uzraudzītu ierīci un pārvaldītu profilu, un neuzraudzīts lietotājs var noņemt profilu jebkurā laikā. Nepiegādājiet dizainu, kas atkarīgs no always-on, ja vien flote nav uzraudzīta.

5. solis: pierādiet ceļu, nevis etiķeti

tun, tap, ppp vai ipsec saskarņu skenēšana pierāda, ka VPN ir konfigurēts, nevis ka jūsu pieprasījums to izmantoja. NWPathMonitor ar usesInterfaceType(.other) saka, ka virtuālā saskarne ir pieejama, un viability handler var pārbaudīt vienu resursdatoru. Neviens no tiem nepierāda izejas ceļu, tāpēc apvienojiet tos ar pieprasījumu uz resursu, ko var sasniegt tikai tunelis. Saskarņu nosaukumi ir diagnostikas palīgs, nekad vārti, uz kuriem lietotnes loģikai būtu jāsazarojas.

Lauka pārbaudei salīdziniet publisko adresi ar tuneli un bez tā un iegūstiet tikai iekšēju lapu. Statusa izsaukums var ziņot par savienojumu, kamēr provider pārrunā, tāpēc ļaujiet resursa rezultātam izlemt un uzskatiet statusu par papildu pierādījumu.