iOS VPN API: NEVPNManager, tunnel-leverandør eller profil?

Tre forskjellige produkter svarer til navnet iOS VPN, og de deler ikke én API. Personal VPN bruker systemets innebygde IPsec- og IKEv2-transporter. Custom tunnel kjører din egen protokoll inne i en network extension. Configuration profile konfigurerer en av dem og kan legge til on-demand-atferd. Å velge etter transporten du må snakke med er raskere enn å velge etter hvilken veiledning som ble kompilert først.

Kjør kontrollene nedenfor i rekkefølge, fordi hvert trinn forutsetter at det forrige ga en gyldig konfigurasjon.

Trinn 1: velg etter transport

Hvis serveren er IKEv2 eller IPsec i Cisco-stil, holder NEVPNManager, og systemtransporter følger gratis. Hvis serveren snakker OpenVPN, WireGuard eller noe annet, kan ikke NEVPNManager hjelpe: den har ingen krok for en tredjepartsprotokoll. Det tilfellet krever NETunnelProviderManager med en packet tunnel provider som implementerer protokollen. En profil distribuerer bare konfigurasjon, og den kan ikke legge til en transport som operativsystemet mangler.

PPTP er ikke et mål på dagens systemer. Shared-secret IPsec forventer fortsatt gruppenavnet i remoteIdentifier, et keychain-element som holder hemmeligheten, og utvidet autentisering når serveren ber om et brukernavn. Hver manglende del vises som den samme generiske konfigurasjonsfeilen, så legg til alle før du feilsøker noe annet.

Trinn 2: respekter rekkefølgen lagre, laste, starte

NEVPNManager skriver til preferences, leser dem tilbake, og starter først da. Fyll ut protokoll- og manager-objektene, kall saveToPreferences, kall loadFromPreferences, og kall startVPNTunnel fra load completion handler. Å starte før lastingen kommer tilbake gir en configuration-invalid-feil, NEVPNErrorDomain code 1, på en konfigurasjon som ellers er riktig.

Formen er kort nok til å holde på ett sted:

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

startVPNTunnel returnerer når forespørselen er akseptert, ikke når tunnelen er oppe. Observer NEVPNStatusDidChange og les connection.status for den virkelige tilstanden. En app som antar suksess på kallstedet rapporterer en tilkoblet VPN mens extensionen fortsatt forhandler. Statusen connecting er normal et øyeblikk; en status som aldri forlater den, er feilen som er verdt å logge.

Trinn 3: gi provider-prosessen det den trenger

Custom transport kjører i en separat prosess med sin egen bundle identifier og sin egen entitlement. Både container-appen og provideren trenger network-extension-entitlementen ved signering, og en Developer ID-build utenfor App Store må fortsatt bære den i provisioning profile. En manglende entitlement ser ut som en protokollfeil fordi extensionen rett og slett ikke starter.

Det finnes ingen offentlig socket descriptor å låne. NEPacketTunnelProvider gir deg NEPacketTunnelFlow med read, write og cancel, og kode som griper etter private nøkkelstier bryter mellom utgivelser. Provideren fortsetter å kjøre mens appen er i bakgrunnen, så container-appen trenger ingen bakgrunnsmodus for det.

Trinn 4: on-demand er et regelsett, ikke en bryter

isOnDemandEnabled armerer bare reglene; NEOnDemandRuleConnect og søsknene bestemmer når tunnelen kommer opp. En evaluate-connection-regel med en probe-URL er bare så god som den URL-en. Hvis probe svarer uten tunnelen, konkluderer regelen at det private nettverket allerede er nåbart og kobler aldri til, så pek den mot noe som bare svarer fra innsiden.

Always-on er et eget løfte. Det krever en overvåket enhet og en administrert profil, og en ikke-overvåket bruker kan fjerne en profil når som helst. Ikke lever en design som avhenger av always-on med mindre flåten er overvåket.

Trinn 5: bevis veien, ikke etiketten

Å skanne etter tun-, tap-, ppp- eller ipsec-grensesnitt beviser at en VPN er konfigurert, ikke at forespørselen din brukte den. NWPathMonitor med usesInterfaceType(.other) sier at et virtuelt grensesnitt er tilgjengelig, og en viability handler kan teste én vert. Ingen av dem beviser utgangsveien, så kombiner dem med en forespørsel til en ressurs bare tunnelen kan nå. Grensesnittnavn er en diagnostisk hjelp, aldri en port som applikasjonslogikk bør forgrene seg på.

For en feltkontroll, sammenlign den offentlige adressen med og uten tunnelen og hent en bare-intern side. Et statuskall kan rapportere tilkoblet mens provideren forhandler, så la resultatet fra ressursen avgjøre og behandle statusen som støttende bevis.