VPN-API's yn iOS: NEVPNManager, tunnelprovider of profyl?
Kies de API op grûn fan it ferfier dat jo sprekke moatte, en bewize dan dat de tunnel ferkear draacht: folchoarder bewarje, lade, starte, rjochten fan de provider en regels op oanfraach.
Trije ferskillende produkten beantwurdzje oan de namme VPN yn iOS, en se diele net ien API. Persoanlike VPN riidt op 'e ynboude IPsec- en IKEv2-ferfieren fan it systeem. In oanpaste tunnel rint jo eigen protokol binnen in netwurkútwreiding. En in konfiguraasjeprofyl konfigurearret ien fan beide en kin hâlden op oanfraach tafoegje. Kieze op grûn fan it ferfier dat jo sprekke moatte is flugger as kieze op grûn fan 'e tutorial dy't it earst kompilearre.
Fier de kontrôles hjirûnder yn folchoarder út, want elke stap giet derfan út dat de foarige in jildige konfiguraasje oplevere hat.
Stap 1: kies op grûn fan ferfier
As de tsjinner IKEv2 of IPsec yn Cisco-styl is, is NEVPNManager genôch en komme de systeemferfieren fergees. As de tsjinner OpenVPN, WireGuard of wat oars sprekt, kin NEVPNManager net helpe: it hat gjin heak foar in protokol fan in tredde partij. Dat gefal hat NETunnelProviderManager nedich mei in pakkettunnelprovider dy't it protokol ymplemintearret. In profyl ferspriedt allinnich konfiguraasje en kin gjin ferfier tafoegje dat it bestjoeringssysteem net hat.
PPTP is gjin doel op 'e hjoeddeiske systemen. IPsec mei in dielde geheim ferwachtet noch de groepsnamme yn remoteIdentifier, in kaaihingstelm item dat it geheim hâldt en útwreide autentikaasje as de tsjinner om in brûkersnamme freget. Elk ûntbrekkend part komt nei foaren as deselde algemiene konfiguraasjeflater, dus foegje se allegear ta foardat jo wat oars debugge.
Stap 2: respektearje de folchoarder bewarje, lade, starte
NEVPNManager skriuwt nei foarkarren, lêst se werom en startet pas dêrnei. Folje de protokol- en behearderobjekten yn, rop saveToPreferences oan, rop loadFromPreferences oan en rop startVPNTunnel oan fanút de foltôgingshandler fan it laden. Starte foardat it laden weromkomt jout in flater foar ûnjildige konfiguraasje, koade 1 yn NEVPNErrorDomain, op in konfiguraasje dy't oars korrekt is.
De foarm is koart genôch om op ien plak te hâlden:
manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }
startVPNTunnel komt werom as it fersyk akseptearre is, net as de tunnel omheech is. Observearje NEVPNStatusDidChange en lês connection.status foar de echte tastân. In app dy't sukses by it opropplak oannimt, rapportearret in ferbûn VPN wylst de útwreiding noch ûnderhannellet. In tastân fan ferbinen is in momint normaal; in tastân dy't dêr nea út komt is de flater dy't it logjen wurdich is.
Stap 3: jou it providerproses wat it nedich hat
In oanpaste ferfier rint yn in apart proses mei syn eigen bundelidentifikaasje en syn eigen rjocht. Sawol de kontenerapp as de provider hawwe by it ûndertekenjen it rjocht foar netwurkútwreiding nedich, en in build mei Developer ID bûten de App Store moat it noch altyd yn it foarsjeningsprofyl drage. In ûntbrekkend rjocht liket op in protokolf later, want de útwreiding start gewoan net.
Der is gjin iepenbier socketbeskriuwer om te lienen. NEPacketTunnelProvider jout jo NEPacketTunnelFlow mei read, write en cancel, en koade dy't nei privee kaaispaden rikt, brekt tusken releases. De provider bliuwt rinnen wylst de app op 'e eftergrûn is, dus de kontener hat dêrfoar gjin eftergrûnmodus nedich.
Stap 4: op oanfraach is in regelset, gjin skeakel
isOnDemandEnabled bewapenet allinnich de regels; NEOnDemandRuleConnect en syn bruorren beslute wannear't de tunnel omheech komt. In regel foar ferbiningsevaluaasje mei in probe-URL is mar sa goed as dy URL. As de probe antwurdet sûnder de tunnel, konkludearret de regel dat it privee netwurk al berikber is en ferbynt nea, dus rjochtsje him op eat dat allinnich fan binnen antwurdet.
Altyd-oan is in apart ûnthjit. It hat in tafersjochte apparaat en in beheard profyl nedich, en in brûker sûnder tafersjoch kin in profyl fuorthelje wannear't er wol. Leverje gjin ûntwerp dat fan altyd-oan ôfhinklik is, útsein as de float ûnder tafersjoch is.
Stap 5: bewize de wei, net it label
Skanne nei tun-, tap-, ppp- of ipsec-ynterfaces bewizet dat in VPN konfigurearre is, net dat jo fersyk it brûkt hat. NWPathMonitor mei usesInterfaceType(.other) seit dat in firtuele ynterface beskikber is, en in libbensfetberenshandler kin ien host teste. Gjin fan beide bewizet it útgongswei, dus kombinearje se mei in fersyk nei in boarne dy't allinnich de tunnel berikke kin. Ynterfacenammen binne in diagnostyske help, nea in poarte dêr't applikaasjelogika op fertakje moat.
Foar in fjildkontrôle fergelykje it iepenbiere adres mei en sûnder de tunnel en helje in side op dy't allinnich yntern is. In tastânoprop kin ferbûn rapportearje wylst de provider ûnderhannellet, dus lit it resultaat fan 'e boarne beslute en behannelje de tastân as stypjend bewiis.