iOS VPN API: NEVPNManager, pružatelj tunela ili profil?

Tri različita proizvoda odgovaraju na naziv iOS VPN i ne dijele API. Personal VPN koristi ugrađene IPsec i IKEv2 transporte sustava. Custom tunnel pokreće vaš vlastiti protokol unutar network extensiona. Configuration profile konfigurira bilo koji od njih i može dodati on-demand ponašanje. Odabir prema transportu s kojim morate razgovarati brži je od odabira prema onom tutorijalu koji se prvi kompajlirao.

Pokrenite provjere u nastavku redom jer svaki korak pretpostavlja da je prethodni proizveo valjanu konfiguraciju.

Korak 1: odaberite prema transportu

Ako je poslužitelj IKEv2 ili IPsec u Cisco stilu, NEVPNManager je dovoljan i sistemski transporti dolaze besplatno. Ako poslužitelj govori OpenVPN, WireGuard ili bilo što drugo, NEVPNManager ne može pomoći: nema kuku za protokol treće strane. Taj slučaj traži NETunnelProviderManager s packet tunnel providerom koji implementira protokol. Profil samo distribuira konfiguraciju i ne može dodati transport koji operativni sustav nema.

PPTP nije cilj na trenutnim sustavima. IPsec sa zajedničkom tajnom još uvijek očekuje naziv grupe u remoteIdentifieru, keychain stavku koja drži tajnu i proširenu autentifikaciju kad poslužitelj zatraži korisničko ime. Svaki dio koji nedostaje pojavljuje se kao ista generička pogreška konfiguracije, pa ih dodajte sve prije nego počnete ispravljati bilo što drugo.

Korak 2: poštujte redoslijed spremanja, učitavanja i pokretanja

NEVPNManager piše u preferences, čita ih natrag i tek onda pokreće. Ispunite protokol i manager objekte, pozovite saveToPreferences, pozovite loadFromPreferences i pozovite startVPNTunnel iz load completion handlera. Pokretanje prije nego se učitavanje vrati proizvodi pogrešku configuration-invalid, NEVPNErrorDomain code 1, na konfiguraciji koja je inače ispravna.

Oblik je dovoljno kratak da stane na jedno mjesto:

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

startVPNTunnel vraća se kad je zahtjev prihvaćen, a ne kad je tunel podignut. Promatrajte NEVPNStatusDidChange i čitajte connection.status za stvarno stanje. Aplikacija koja pretpostavlja uspjeh na mjestu poziva prijavljuje povezani VPN dok extension još pregovara. Status connecting normalan je na trenutak; status koji ga nikad ne napusti je kvar koji vrijedi zabilježiti.

Korak 3: dajte provider procesu ono što mu treba

Custom transport radi u zasebnom procesu s vlastitim bundle identifierom i vlastitim entitlementom. I container aplikacija i provider trebaju network-extension entitlement u vrijeme potpisivanja, a Developer ID build izvan App Storea mora ga nositi u provisioning profileu. Entitlement koji nedostaje izgleda kao bug protokola jer se extension jednostavno ne pokrene.

Nema javnog socket descriptora za posudbu. NEPacketTunnelProvider daje vam NEPacketTunnelFlow s read, write i cancel, a kod koji poseže za privatnim putanjama ključeva lomi se između izdanja. Provider nastavlja raditi dok je aplikacija u pozadini, pa container aplikaciji za to ne treba pozadinski način rada.

Korak 4: on-demand je skup pravila, ne prekidač

isOnDemandEnabled samo naoružava pravila; NEOnDemandRuleConnect i njegova braća odlučuju kada se tunel podiže. Pravilo evaluate-connection s probe URL-om vrijedi koliko i taj URL. Ako probe odgovori bez tunela, pravilo zaključuje da je privatna mreža već dosežna i nikad se ne povezuje, pa ga usmjerite na nešto što odgovara samo iznutra.

Always-on je zasebno obećanje. Treba nadzirani uređaj i upravljani profil, a nenadzirani korisnik može ukloniti profil kad god želi. Ne isporučujte dizajn koji ovisi o always-onu osim ako je flota nadzirana.

Korak 5: dokažite put, ne oznaku

Skeniranje tun, tap, ppp ili ipsec sučelja dokazuje da je VPN konfiguriran, ne da ga je vaš zahtjev koristio. NWPathMonitor s usesInterfaceType(.other) kaže da je virtualno sučelje dostupno, a viability handler može testirati jednog hosta. Nijedno ne dokazuje izlazni put, pa ih spojite sa zahtjevom prema resursu do kojeg samo tunel može doći. Nazivi sučelja dijagnostička su pomoć, nikad vrata na kojima bi aplikacijska logika trebala granati.

Za provjeru na terenu usporedite javnu adresu sa i bez tunela i dohvatite stranicu samo za interno. Statusni poziv može prijaviti povezanost dok provider pregovara, pa neka rezultat resursa odluči, a status tretirajte kao popratni dokaz.