iOS VPN API: NEVPNManager, veitandi tunnels eða prófíla?

Þrjár mismunandi vörur bera nafnið iOS VPN og þær deila ekki API. Personal VPN notar innbyggðu IPsec og IKEv2 flutningana í kerfinu. Custom tunnel keyrir þitt eigið prótókol inni í network extension. Configuration profile stillir hvort sem er og getur bætt við on-demand hegðun. Að velja eftir flutningnum sem þú verður að tala við er hraðara en að velja eftir því hvaða kennsluefni þýddist fyrst.

Keyrðu prófin hér að neðan í röð, því hvert skref gerir ráð fyrir að það fyrra hafi skilað gildri uppsetningu.

Skref 1: veldu eftir flutningi

Ef þjónninn er IKEv2 eða IPsec í Cisco stíl nægir NEVPNManager og flutningar kerfisins fylgja frítt. Ef þjónninn talar OpenVPN, WireGuard eða eitthvað annað getur NEVPNManager ekki hjálpað: það hefur engan krók fyrir prótókol þriðja aðila. Það tilfelli þarf NETunnelProviderManager með packet tunnel provider sem útfærir prótókolið. Profile dreifir aðeins uppsetningu og getur ekki bætt við flutningi sem stýrikerfið hefur ekki.

PPTP er ekki markmið á núverandi kerfum. IPsec með sameiginlegu leyndarmáli býst enn við hópnum í remoteIdentifier, keychain atriði sem geymir leyndarmálið og aukinni auðkenningu þegar þjónninn biður um notandanafn. Hver hluti sem vantar birtist sem sama almenna uppsetningarvillan, svo bættu öllum við áður en þú kembir eitthvað annað.

Skref 2: virðu röðina vistun, hleðsla, ræsing

NEVPNManager skrifar í preferences, les þau til baka og byrjar síðan. Fylltu út prótókol- og manager-hlutina, kallaðu í saveToPreferences, kallaðu í loadFromPreferences og kallaðu í startVPNTunnel úr load completion handler. Að byrja áður en hleðslan kemur til baka framleiðir configuration-invalid villu, NEVPNErrorDomain code 1, á uppsetningu sem er annars rétt.

Lögunin er nógu stutt til að geyma á einum stað:

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

startVPNTunnel kemur til baka þegar beiðnin er samþykkt, ekki þegar tunnillinn er kominn upp. Fylgstu með NEVPNStatusDidChange og lestu connection.status fyrir raunverulegt ástand. Forrit sem gerir ráð fyrir árangri við kallið tilkynnir tengt VPN á meðan extension er enn að semja. Connecting staða er eðlileg í smástund; staða sem fer aldrei út úr henni er bilunin sem er þess virði að skrá.

Skref 3: gefðu provider ferlinu það sem það þarf

Custom transport keyrir í sér ferli með eigin bundle identifier og eigin entitlement. Bæði container forritið og provider þurfa network-extension entitlement við undirritun, og Developer ID build utan App Store verður samt að bera það í provisioning profile. Entitlement sem vantar lítur út eins og prótókolvilla því extension byrjar einfaldlega ekki.

Það er enginn opinber socket descriptor til að fá að láni. NEPacketTunnelProvider gefur þér NEPacketTunnelFlow með read, write og cancel, og kóði sem teygir sig í einkalyklaslóðir brotnar milli útgáfa. Provider heldur áfram að keyra á meðan forritið er í bakgrunni, svo container forritið þarf enga bakgrunnsstillingu fyrir það.

Skref 4: on-demand er reglusett, ekki rofi

isOnDemandEnabled virkjar aðeins reglurnar; NEOnDemandRuleConnect og systkin þess ákveða hvenær tunnillinn kemur upp. evaluate-connection regla með probe URL er aðeins eins góð og þessi URL. Ef probe svarar án tunnelsins dregur reglan þá ályktun að einkanetið sé þegar aðgengilegt og tengist aldrei, svo beindu henni að einhverju sem svarar aðeins innan frá.

Always-on er sérstakt loforð. Það þarf stýrt tæki og stýrða prófílu, og notandi án eftirlits getur fjarlægt prófílu hvenær sem hann vill. Ekki senda hönnun sem byggir á always-on nema flotinn sé undir eftirliti.

Skref 5: sannaðu leiðina, ekki merkið

Að skanna tun, tap, ppp eða ipsec tengi sannar að VPN sé uppsett, ekki að beiðnin þín hafi notað það. NWPathMonitor með usesInterfaceType(.other) segir að sýndartengi sé tiltækt, og viability handler getur prófað einn hýsil. Hvort tveggja sannar ekki útleiðina, svo sameinaðu þau beiðni á auðlind sem aðeins tunnillinn nær til. Tengjaheiti eru greiningaraðstoð, aldrei hlið sem forritarökfræði á að greinast á.

Fyrir vettvangspróf skaltu bera saman opinbert vistfang með og án tunnelsins og sækja síðu sem er aðeins innri. Statuskall getur tilkynnt tengingu á meðan provider semur, svo láttu niðurstöðu auðlindarinnar ráða og meðhöndla stöðuna sem stoðgögn.