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

Tre ulike produkt svarar til namnet iOS VPN, og dei deler ikkje éin API. Personal VPN brukar dei innebygde IPsec- og IKEv2-transportane i systemet. Custom tunnel køyrer din eigen protokoll inne i ein network extension. Configuration profile konfigurerer ein av dei og kan leggje til on-demand-åtferd. Å velje etter transporten du må snakke med er raskare enn å velje etter kva rettleiing som vart kompilert først.

Køyr kontrollane nedanfor i rekkjefølgje, fordi kvart steg føreset at det førre gav ein gyldig konfigurasjon.

Steg 1: vel etter transport

Viss serveren er IKEv2 eller IPsec i Cisco-stil, held NEVPNManager, og systemtransportane følgjer gratis. Viss serveren snakkar OpenVPN, WireGuard eller noko anna, kan ikkje NEVPNManager hjelpe: det har ingen krok for ein tredjepartsprotokoll. Det tilfellet krev NETunnelProviderManager med ein packet tunnel provider som implementerer protokollen. Ein profil distribuerer berre konfigurasjon, og han kan ikkje leggje til ein transport som operativsystemet manglar.

PPTP er ikkje eit mål på dagens system. Shared-secret IPsec ventar framleis gruppenamnet i remoteIdentifier, eit keychain-element som held løyndomen, og utvida autentisering når serveren ber om eit brukarnamn. Kvar manglande del viser seg som den same generiske konfigurasjonsfeilen, så legg til alle før du feilsøkjer noko anna.

Steg 2: respekter rekkjefølgja lagre, laste, starte

NEVPNManager skriv til preferences, les dei tilbake, og startar først då. Fyll ut protokoll- og manager-objekta, kall saveToPreferences, kall loadFromPreferences, og kall startVPNTunnel frå load completion handler. Å starte før lastinga kjem tilbake gjev ein configuration-invalid-feil, NEVPNErrorDomain code 1, på ein konfigurasjon som elles er riktig.

Forma er kort nok til å halde på ein stad:

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

startVPNTunnel kjem tilbake når førespurnaden er godteken, ikkje når tunnelen er oppe. Observer NEVPNStatusDidChange og les connection.status for den verkelege tilstanden. Ein app som føreset suksess på kallstaden rapporterer ein tilkopla VPN medan extensionen framleis forhandlar. Statusen connecting er normal eit augneblink; ein status som aldri forlèt han, er feilen som er verdt å logge.

Steg 3: gje provider-prosessen det han treng

Custom transport køyrer i ein eigen prosess med sin eigen bundle identifier og sin eigen entitlement. Både container-appen og provideren treng network-extension-entitlementen ved signering, og ein Developer ID-build utanfor App Store må framleis bere han i provisioning profile. Ein manglande entitlement ser ut som ein protokollfeil fordi extensionen rett og slett ikkje startar.

Det finst ingen offentleg socket descriptor å låne. NEPacketTunnelProvider gjev deg NEPacketTunnelFlow med read, write og cancel, og kode som grip etter private nøkkelstiar bryt mellom utgåver. Provideren held fram med å køyre medan appen er i bakgrunnen, så container-appen treng ingen bakgrunnsmodus for det.

Steg 4: on-demand er eit regelsett, ikkje ein brytar

isOnDemandEnabled armerer berre reglane; NEOnDemandRuleConnect og syskena bestemmer når tunnelen kjem opp. Ein evaluate-connection-regel med ein probe-URL er berre så god som den URL-en. Viss probe svarar utan tunnelen, konkluderer regelen at det private nettet allereie er nåbart og koplar aldri til, så peik han mot noko som berre svarar frå innsida.

Always-on er eit eige løfte. Det krev ein overvaka eining og ein administrert profil, og ein brukar utan overvaking kan fjerne ein profil når som helst. Ikkje lever ein design som er avhengig av always-on med mindre flåten er overvaka.

Steg 5: prov veggen, ikkje etiketten

Å skanne etter tun-, tap-, ppp- eller ipsec-grensesnitt provar at ein VPN er konfigurert, ikkje at førespurnaden din brukte han. NWPathMonitor med usesInterfaceType(.other) seier at eit virtuelt grensesnitt er tilgjengeleg, og ein viability handler kan teste éin vert. Ingen av dei provar utgangsvegen, så kombiner dei med ein førespurnad til ein ressurs berre tunnelen kan nå. Grensesnittnamn er ei diagnostisk hjelp, aldri ei port som applikasjonslogikk bør forgreine seg på.

For ein feltkontroll, samanlikn den offentlege adressa med og utan tunnelen og hent ei berre-intern side. Eit statuskall kan rapportere tilkopla medan provideren forhandlar, så la resultatet frå ressursen avgjere og handsam statusen som støttande prov.