iOS se VPN-API's: NEVPNManager, tonnelverskaffer of profiel?

Drie verskillende produkte reageer op die naam iOS VPN, en hulle deel nie een API nie. Persoonlike VPN ry op die stelsel se ingeboude IPsec- en IKEv2-vervoerlae. 'n Pasgemaakte tonnel laat jou eie protokol binne 'n netwerkuitbreiding loop. 'n Konfigurasieprofiel konfigureer enigeen van die twee en kan gedrag op aanvraag byvoeg. Om te kies volgens die vervoerlaag wat jy moet praat, is vinniger as om te kies volgens watter handleiding eerste gekompileer het.

Voer die kontroles hieronder in volgorde uit, want elke stap aanvaar dat die vorige een 'n geldige konfigurasie opgelewer het.

Stap 1: kies volgens vervoerlaag

As die bediener IKEv2 of IPsec in Cisco-styl is, is NEVPNManager genoeg en kom die stelselvervoerlae verniet. As die bediener OpenVPN, WireGuard of enigiets anders praat, kan NEVPNManager nie help nie: dit het geen haak vir 'n protokol van 'n derde party nie. Daardie geval het NETunnelProviderManager nodig met 'n pakkiettonnelverskaffer wat die protokol implementeer. 'n Profiel versprei net konfigurasie en kan nie 'n vervoerlaag byvoeg wat die bedryfstelsel nie het nie.

PPTP is nie 'n teiken op huidige stelsels nie. IPsec met 'n gedeelde geheim verwag steeds die groepnaam in remoteIdentifier, 'n sleutelbositem wat die geheim hou, en uitgebreide verifikasie wanneer die bediener om 'n gebruikersnaam vra. Elke ontbrekende stuk wys as dieselfde generiese konfigurasiefout, so voeg hulle almal by voordat jy enigiets anders ontfout.

Stap 2: respekteer die volgorde stoor, laai, begin

NEVPNManager skryf na voorkeure, lees hulle terug en begin eers dan. Vul die protokol- en bestuurderobjekte, roep saveToPreferences, roep loadFromPreferences en roep startVPNTunnel vanuit die voltooiingshanteerder van die laai. Om te begin voordat die laai terugkeer, lewer 'n konfigurasie-ongeldig-fout, NEVPNErrorDomain-kode 1, op 'n konfigurasie wat andersins korrek is.

Die vorm is kort genoeg om op een plek te hou:

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

startVPNTunnel keer terug wanneer die versoek aanvaar is, nie wanneer die tonnel op is nie. Let op NEVPNStatusDidChange en lees connection.status vir die werklike toestand. 'n App wat sukses by die oproepplek aanneem, rapporteer 'n gekoppelde VPN terwyl die uitbreiding nog onderhandel. 'n Toestand van verbind is 'n oomblik normaal; 'n toestand wat dit nooit verlaat nie, is die fout wat die moeite werd is om te log.

Stap 3: gee die verskafferproses wat hy nodig het

'n Pasgemaakte vervoerlaag loop in 'n aparte proses met sy eie bondelidentifiseerder en sy eie regtiging. Beide die houer-app en die verskaffer het by ondertekeningstyd die netwerkuitbreiding-regtiging nodig, en 'n Developer ID-bou buite die App Store moet dit steeds in die voorsieningsprofiel dra. 'n Ontbrekende regtiging lyk soos 'n protokolfout, want die uitbreiding begin eenvoudig nie.

Daar is geen openbare sokkelbeskrywer om te leen nie. NEPacketTunnelProvider gee jou NEPacketTunnelFlow met read, write en cancel, en kode wat na private sleutelpaaie gryp, breek tussen weergawes. Die verskaffer hou aan loop terwyl die app in die agtergrond is, so die houer-app het geen agtergrondmodus daarvoor nodig nie.

Stap 4: op aanvraag is 'n stel reels, nie 'n skakelaar nie

isOnDemandEnabled maak net die reels gereed; NEOnDemandRuleConnect en sy broers besluit wanneer die tonnel opkom. 'n Reel wat die verbinding evalueer met 'n peil-URL is net so goed soos daardie URL. As die peiling antwoord sonder die tonnel, kom die reel tot die gevolgtrekking dat die private netwerk reeds bereikbaar is en verbind nooit nie, so rig dit op iets wat net van binne af antwoord.

Altyd-aan is 'n aparte belofte. Dit vereis 'n toesigtoestel en 'n bestuurde profiel, en 'n gebruiker sonder toesig kan 'n profiel verwyder wanneer hy wil. Moenie 'n ontwerp lewer wat van altyd-aan afhang nie, tensy die vloot onder toesig is.

Stap 5: bewys die pad, nie die etiket nie

Om te soek na tun-, tap-, ppp- of ipsec-koppelvlakke bewys dat 'n VPN gekonfigureer is, nie dat jou versoek dit gebruik het nie. NWPathMonitor met usesInterfaceType(.other) se 'n virtuele koppelvlak is beskikbaar, en 'n lewensvatbaarheidshanteerder kan een gasheer toets. Nie een bewys die uitgangspad nie, so kombineer hulle met 'n versoek na 'n hulpbron wat net die tonnel kan bereik. Koppelvlakname is 'n diagnostiese hulp, nooit 'n hek waarop toepassingslogika moet vertak nie.

Vir 'n veldkontrole, vergelyk die openbare adres met en sonder die tonnel en haal 'n bladsy wat net intern is. 'n Statusoproep kan verbind rapporteer terwyl die verskaffer onderhandel, so laat die hulpbronuitslag besluit en behandel die status as ondersteunende bewyse.