iOS-i VPN API-d: NEVPNManager, tunneliteenuse pakkuja või profiil?

Valige API selle transpordi järgi, millega peate rääkima, ja tõestage siis, et tunnel kannab liiklust: salvestamise, laadimise ja käivitamise järjekord, pakkuja õigused ja nõudmisel reeglid.

iOS-i nime VPN all vastavad kolm erinevat toodet ja need ei jaga üht API-t. Isiklik VPN sõidab süsteemi sisseehitatud IPsec- ja IKEv2-transportidel. Kohandatud tunnel käivitab teie enda protokolli võrgu laienduse sees. Ja konfiguratsiooniprofiil seadistab kumbagi neist ning võib lisada nõudmisel käitumise. Valimine transpordi järgi, millega peate rääkima, on kiirem kui valimine selle õpetuse järgi, mis esimesena kompileerus.

Käivitage allolevad kontrollid järjekorras, sest iga samm eeldab, et eelmine andis kehtiva konfiguratsiooni.

Samm 1: valige transpordi järgi

Kui server on IKEv2 või Cisco-stiilis IPsec, piisab NEVPNManagerist ja süsteemi transpordid tulevad tasuta. Kui server räägib OpenVPN, WireGuardiga või millegi muuga, ei saa NEVPNManager aidata: sellel pole konksu kolmanda osapoole protokolli jaoks. See juhtum vajab NETunnelProviderManagerit paketitunneli pakkujaga, mis protokolli rakendab. Profiil ainult jaotab konfiguratsiooni ega saa lisada transporti, mida operatsioonisüsteemil pole.

PPTP ei ole praegustel süsteemidel sihtmärk. Ühise saladusega IPsec ootab endiselt grupinime remoteIdentifieris, saladust hoidvat võtmehoidla üksust ja laiendatud autentimist, kui server küsib kasutajanime. Iga puuduv osa ilmub sama üldise konfiguratsiooniveana, seega lisage need kõik enne, kui hakkate midagi muud siluma.

Samm 2: järgige järjekorda salvesta, laadi, käivita

NEVPNManager kirjutab eelistustesse, loeb need tagasi ja alles siis käivitab. Täitke protokolli- ja halduriobjektid, kutsuge saveToPreferences, kutsuge loadFromPreferences ja kutsuge startVPNTunnel laadimise lõpetamise käitlejast. Käivitamine enne laadimise naasmist annab kehtetu konfiguratsiooni vea, kood 1 NEVPNErrorDomainis, konfiguratsioonil, mis on muidu õige.

Kuju on piisavalt lühike, et hoida seda ühes kohas:

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

startVPNTunnel naaseb siis, kui taotlus on vastu võetud, mitte siis, kui tunnel on püsti. Jälgige NEVPNStatusDidChangei ja lugege tegeliku oleku jaoks connection.statusi. Rakendus, mis eeldab kutsekohas õnnestumist, teatab ühendatud VPN-ist, samal ajal kui laiendus alles läbirääkimisi peab. Ühendamise olek on hetkeks normaalne; olek, mis sellest kunagi ei välju, on logimist väärt rike.

Samm 3: andke pakkuja protsessile, mida see vajab

Kohandatud transport töötab eraldi protsessis oma komplekti identifikaatori ja oma õigusega. Nii konteinerrakendus kui ka pakkuja vajavad allkirjastamise ajal võrgulaienduse õigust ja Developer ID-ga ehitatud versioon väljaspool App Store'i peab seda ikkagi provisjoneerimisprofiilis kandma. Puuduv õigus näeb välja nagu protokolliviga, sest laiendus lihtsalt ei käivitu.

Laenata pole ühtegi avalikku soketi kirjeldajat. NEPacketTunnelProvider annab teile NEPacketTunnelFlowi koos read, write ja canceliga ning privaatsete võtmeteradade järele haarav kood laguneb väljaannete vahel. Pakkuja töötab edasi, kui rakendus on taustal, seega ei vaja konteiner selleks taustarežiimi.

Samm 4: nõudmisel toimimine on reeglistik, mitte lüliti

isOnDemandEnabled ainult viritab reeglid; NEOnDemandRuleConnect ja selle õed-vennad otsustavad, millal tunnel üles tuleb. Ühenduse hindamise reegel probe-URL-iga on täpselt nii hea kui see URL. Kui probe vastab ilma tunnelita, järeldab reegel, et privaatvõrk on juba kättesaadav, ega ühenda kunagi, seega suunake see millelegi, mis vastab ainult seestpoolt.

Alati sisse on eraldi lubadus. See vajab järelevalvega seadet ja hallatavat profiili ning järelevalveta kasutaja võib profiili igal hetkel eemaldada. Ärge tarnige disaini, mis sõltub alati sisse olekust, kui seadmepark pole järelevalve all.

Samm 5: tõestage tee, mitte silt

tun-, tap-, ppp- või ipsec-liideste skaneerimine tõestab, et VPN on seadistatud, mitte et teie taotlus seda kasutas. NWPathMonitor koos usesInterfaceType(.other) ütleb, et virtuaalne liides on saadaval, ja elujõulisuse käitleja saab testida ühte hosti. Kumbki ei tõesta väljundteed, seega ühendage need taotlusega ressursile, kuhu pääseb ainult tunnel. Liidesenimed on diagnostiline abivahend, mitte kunagi värav, mille peale rakenduseloogika peaks hargnema.

Välitingimuste kontrolliks võrrelge avalikku aadressi tunneliga ja ilma ning tooge ainult sisemine leht. Olekukutse võib teatada ühendatud olekust, samal ajal kui pakkuja läbiräägib, seega laske ressursi tulemusel otsustada ja käsitlege olekut toetava tõendina.

Seotud artiklid