iOS VPN API: NEVPNManager, туннель провайдері немесе профиль?

iOS VPN деген атқа үш түрлі өнім жауап береді және олар бір API-ді бөліспейді. Personal VPN жүйенің кірістірілген IPsec және IKEv2 транспорттарын пайдаланады. Custom tunnel өз протоколыңызды network extension ішінде жүргізеді. Configuration profile екеуінің бірін конфигурациялайды және on-demand мінез-құлқын қоса алады. Сөйлесуге тиіс транспорт бойынша таңдау, бірінші компиляцияланған tutorial бойынша таңдаудан жылдамырақ.

Төмендегі тексерулерді ретімен орындаңыз, өйткені әр қадам алдыңғысы дұрыс конфигурация шығарды деп есептейді.

1-қадам: транспорт бойынша таңдаңыз

Егер сервер IKEv2 немесе Cisco стиліндегі IPsec болса, NEVPNManager жеткілікті және жүйелік транспорттар тегін келеді. Егер сервер OpenVPN, WireGuard немесе басқа нәрсені сөйлесе, NEVPNManager көмектесе алмайды: оның үшінші тарап протоколы үшін ілгегі жоқ. Бұл жағдай протоколды жүзеге асыратын packet tunnel provider-і бар NETunnelProviderManager-ды қажет етеді. Профиль тек конфигурацияны таратады және операциялық жүйеде жоқ транспортты қоса алмайды.

PPTP қазіргі жүйелерде мақсат емес. Shared-secret IPsec әлі де remoteIdentifier ішіндегі топ атауын, құпияны сақтайтын keychain элементін және сервер пайдаланушы атын сұрағанда кеңейтілген аутентификацияны күтеді. Әр жетіспейтін бөлік сол бір жалпы конфигурация қатесі ретінде көрінеді, сондықтан басқа нәрсені жөндеуден бұрын олардың барлығын қосыңыз.

2-қадам: сақтау, жүктеу, іске қосу ретін сақтаңыз

NEVPNManager preferences-ке жазады, оларды қайта оқиды, содан кейін ғана іске қосады. Протокол мен manager объектілерін толтырыңыз, saveToPreferences шақырыңыз, loadFromPreferences шақырыңыз және load completion handler-ден startVPNTunnel шақырыңыз. Жүктеу қайтпай тұрып іске қосу өзгеше дұрыс конфигурацияда configuration-invalid қатесін, NEVPNErrorDomain code 1, тудырады.

Пішін бір жерде сақтауға жеткілікті қысқа:

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

startVPNTunnel сұраныс қабылданғанда қайтады, туннель көтерілгенде емес. NEVPNStatusDidChange-ті бақылаңыз және нақты күй үшін connection.status оқыңыз. Шақыру орнында сәттілік деп есептейтін қолданба extension әлі келіссөз жүргізіп жатқанда VPN қосылды деп хабарлайды. Connecting күйі бір сәтке қалыпты; одан ешқашан шықпайтын күй — журналға жазуға тұрарлық ақау.

3-қадам: provider процесіне қажет нәрсені беріңіз

Custom transport өз bundle identifier-і және өз entitlement-і бар жеке процесте жүреді. Container қолданба да, provider де қол қою кезінде network-extension entitlement-ін қажет етеді, ал App Store-дан тыс Developer ID build оны provisioning profile-де алып жүруі керек. Жетіспейтін entitlement протокол қатесіне ұқсайды, өйткені extension жай ғана іске қосылмайды.

Қарызға алатын жария socket descriptor жоқ. NEPacketTunnelProvider сізге read, write және cancel-мен NEPacketTunnelFlow береді, ал жеке кілт жолдарына жететін код шығарылымдар арасында сынады. Қолданба background-та болғанда provider жұмысын жалғастырады, сондықтан container қолданбаға ол үшін background режимі қажет емес.

4-қадам: on-demand — ережелер жиынтығы, қосқыш емес

isOnDemandEnabled тек ережелерді қаруландырады; NEOnDemandRuleConnect және оның серіктері туннель қашан көтерілетінін шешеді. probe URL-і бар evaluate-connection ережесі сол URL қаншалықты жақсы болса, соншалықты жақсы. Егер probe туннельсіз жауап берсе, ереже жеке желіге қазірдің өзінде қол жеткізуге болады деп қорытындылайды және ешқашан қосылмайды, сондықтан оны тек іштен жауап беретін нәрсеге бағыттаңыз.

Always-on — бөлек уәде. Ол қадағаланатын құрылғы мен басқарылатын профильді қажет етеді, ал қадағаланбайтын пайдаланушы профильді қалаған кезде жоя алады. Флот қадағаланбаса, always-on-ға тәуелді дизайнды шығармаңыз.

5-қадам: белгіні емес, жолды дәлелдеңіз

tun, tap, ppp немесе ipsec интерфейстерін сканерлеу VPN конфигурацияланғанын дәлелдейді, бірақ сұранысыңыз оны пайдаланғанын емес. NWPathMonitor usesInterfaceType(.other)-пен виртуалды интерфейстің қолжетімді екенін айтады, ал viability handler бір хостты тексере алады. Екеуі де шығу жолын дәлелдемейді, сондықтан оларды тек туннель жете алатын ресурсқа сұраныспен біріктіріңіз. Интерфейс атаулары диагностикалық көмекші, қолданба логикасы тармақталатын қақпа емес.

Далалық тексеру үшін жария мекенжайды туннельмен және онсыз салыстырыңыз және тек ішкі бетті алыңыз. Status шақыруы provider келіссөз жүргізіп жатқанда қосылған деп хабарлауы мүмкін, сондықтан шешімді ресурс нәтижесі қабылдасын, ал status-ты қосымша дәлел ретінде қарастырыңыз.