API-t e VPN për iOS: NEVPNManager, ofruesi i tunelit apo profili?

Tre produkte të ndryshme përgjigjen ndaj emrit iOS VPN dhe ato nuk ndajnë një API. Personal VPN udhëton mbi transportet IPsec dhe IKEv2 të integruara në sistem. Custom tunnel ekzekuton protokollin tuaj brenda një network extension. Configuration profile konfiguron cilindo prej tyre dhe mund të shtojë sjellje on-demand. Zgjedhja sipas transportit me të cilin duhet të flisni është më e shpejtë sesa zgjedhja sipas tutorialit që u kompilua i pari.

Ekzekutoni kontrollet më poshtë sipas radhës, sepse çdo hap supozon se ai i mëparshmi prodhoi një konfigurim të vlefshëm.

Hapi 1: zgjidhni sipas transportit

Nëse serveri është IKEv2 ose IPsec në stilin Cisco, NEVPNManager mjafton dhe transportet e sistemit vijnë falas. Nëse serveri flet OpenVPN, WireGuard ose çdo gjë tjetër, NEVPNManager nuk mund të ndihmojë: nuk ka grep për një protokoll të palës së tretë. Ai rast kërkon NETunnelProviderManager me një packet tunnel provider që implementon protokollin. Profili vetëm shpërndan konfigurim dhe nuk mund të shtojë një transport që sistemi operativ nuk e ka.

PPTP nuk është objektiv në sistemet aktuale. IPsec me sekret të përbashkët ende pret emrin e grupit në remoteIdentifier, një artikull keychain që mban sekretin dhe vërtetim të zgjeruar kur serveri kërkon një emër përdoruesi. Çdo pjesë që mungon shfaqet si i njëjti gabim i përgjithshëm konfigurimi, ndaj shtojini të gjitha përpara se të korrigjoni çdo gjë tjetër.

Hapi 2: respektoni rendin ruaj, ngarko, nis

NEVPNManager shkruan në preferences, i lexon përsëri dhe vetëm atëherë nis. Plotësoni objektet e protokollit dhe manager, thirrni saveToPreferences, thirrni loadFromPreferences dhe thirrni startVPNTunnel nga load completion handler. Nisja përpara se ngarkimi të kthehet prodhon një gabim configuration-invalid, NEVPNErrorDomain code 1, në një konfigurim që përndryshe është i saktë.

Forma është mjaft e shkurtër për t'u mbajtur në një vend:

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

startVPNTunnel kthehet kur kërkesa pranohet, jo kur tuneli është lart. Vëzhgoni NEVPNStatusDidChange dhe lexoni connection.status për gjendjen e vërtetë. Një aplikacion që supozon sukses në vendin e thirrjes raporton një VPN të lidhur ndërsa extension-i ende negocion. Gjendja connecting është normale për një çast; gjendja që nuk del kurrë prej saj është dështimi që ia vlen të logohet.

Hapi 3: jepini procesit provider atë që i nevojitet

Custom transport ekzekutohet në një proces të veçantë me bundle identifier të vetin dhe entitlement të vetin. Si aplikacioni container ashtu edhe provider-i kanë nevojë për entitlement-in network-extension në kohën e nënshkrimit, dhe një build Developer ID jashtë App Store duhet ta mbajë atë në provisioning profile. Një entitlement që mungon duket si bug protokolli sepse extension-i thjesht nuk niset.

Nuk ka socket descriptor publik për të huazuar. NEPacketTunnelProvider ju jep NEPacketTunnelFlow me read, write dhe cancel, dhe kodi që shtrihet drejt rrugëve të çelësave privatë thyhet mes versioneve. Provider-i vazhdon të ekzekutohet ndërsa aplikacioni është në sfond, kështu që aplikacioni container nuk ka nevojë për një modalitet sfondi për këtë.

Hapi 4: on-demand është një grup rregullash, jo një çelës

isOnDemandEnabled vetëm armatos rregullat; NEOnDemandRuleConnect dhe vëllezërit e tij vendosin kur ngrihet tuneli. Një rregull evaluate-connection me probe URL vlen aq sa vlen ai URL. Nëse probe përgjigjet pa tunelin, rregulli përfundon se rrjeti privat është tashmë i arritshëm dhe nuk lidhet kurrë, ndaj drejtojeni drejt diçkaje që përgjigjet vetëm nga brenda.

Always-on është një premtim i veçantë. Kërkon një pajisje të mbikëqyrur dhe një profil të menaxhuar, dhe një përdorues i pambikëqyrur mund të heqë një profil kur të dojë. Mos dërgoni një dizajn që varet nga always-on nëse flota nuk është e mbikëqyrur.

Hapi 5: provoni rrugën, jo etiketën

Skanimi për ndërfaqe tun, tap, ppp ose ipsec provon që një VPN është konfiguruar, jo që kërkesa juaj e përdori. NWPathMonitor me usesInterfaceType(.other) thotë se një ndërfaqe virtuale është e disponueshme, dhe një viability handler mund të testojë një host. Asnjëra nuk provon rrugën e daljes, ndaj kombinoni ato me një kërkesë drejt një burimi që vetëm tuneli mund ta arrijë. Emrat e ndërfaqeve janë ndihmë diagnostike, kurrë një portë mbi të cilën logjika e aplikacionit duhet të degëzohet.

Për një kontroll në terren, krahasoni adresën publike me dhe pa tunelin dhe merrni një faqe vetëm të brendshme. Një thirrje statusi mund të raportojë të lidhur ndërsa provider-i negocion, ndaj lëreni rezultatin e burimit të vendosë dhe trajtojeni statusin si provë mbështetëse.