'n Mens kan twee iPhone-programme hê wat albei 'n VPN-inskrywing in Instellings plaas, albei hulself VPN-kliënte noem en byna geen implementering deel nie. Apple noem een van dié integrasies Persoonlike VPN, en dié naam veroorsaak die meeste verwarring. Persoonlike VPN is 'n API vir die skep en bestuur van konfigurasies wat die ingeboude IPsec- of IKEv2-implementering gebruik. 'n Pakkettunnel-verskaffer is die ander model: die program lewer 'n uitbreiding wat die kliëntkant van sy eie protokol implementeer. Alles wat mense daarna uit die etiket aflei, van syfers tot eienaarskap tot of die foon bestuur moet word, is afleiding eerder as 'n stelling.

Wie die tunnel implementeer

Die verdeling bepaal wie verantwoordelik is wanneer iets breek. Met ingeboude IPsec of IKEv2 besit iOS die tunnel-toestandsmasjien en die program besit die konfigurasie en die knoppies. Met 'n verskaffer besit die program albei, so 'n protokol-fout word 'n programopdatering in plaas van 'n bedryfstelselopdatering.

Die vergelyking is kort as jy vra wie die protokol implementeer.

IntegrationApple interfaceProtocol implementation
Personal VPNNEVPNManager with a Personal VPN configurationThe system IPsec or IKEv2 client
Packet tunnelNETunnelProviderManager plus the provider extensionWhatever the extension implements

Die Persoonlike VPN-dokumentasie noem ook die uitdruklike gebruikersmagtigingsversoek wanneer 'n program die eerste keer 'n konfigurasie stoor, wat aan daardie model behoort eerder as aan VPN-programme in die algemeen.

Twee bewerings oor die etiket wat mens moet laat vaar

Die eerste is dat Persoonlike VPN 'n syfer kies. Dit doen nie; die onderhandelde suite kom van die protokol en sy konfigurasie, en 'n Persoonlike-etiket sê niks oor watter een jy gaan kry nie. Die tweede is dat Persoonlike VPN 'n proxy of 'n beperkte tunnel impliseer. Dit impliseer ingeboude IPsec of IKEv2, wat 'n volle tunnel is wanneer die roetes so sê.

Die teenwoordigheid van 'n program is dus geen bewys oor die draadprotokol nie. 'n Derdeparty-kliënt wat WireGuard of OpenVPN praat, is per konstruksie 'n verskafferprogram, want iOS implementeer daardie protokolle nie inheems nie.

Waarom die ondernemingsbewoording mislei

Apple se dokumentasie klassifiseer NETunnelProviderManager-konfigurasies as gewone ondernemings-VPN-konfigurasies. Daardie bewoording is 'n API-kategorie, en dit stoot mense na twee teenoorgestelde foute: om aan te neem dat 'n verbruikerprogram nie die verskaffermodel kan gebruik nie, en om aan te neem dat die foon daarvoor onder toesig moet wees. Nie een volg nie. Verbruikerprogramme lewer gereeld verskaffers, en toesig is 'n aparte vraag oor wie beleid mag afdwing.

Bestuurseienaarskap is daardie vierde vraag, en dit is onafhanklik van albei modelle. 'n Konfigurasie wat deur 'n organisasie geïnstalleer word, dra sy eie identiteit, verkeersomvang en lewensiklusreëls, en dié reis saam met die profiel eerder as met watter program ook al geïnstalleer is. Lees hulle saam met die integrasiemodel, want 'n bestuurde ingeboude profiel en 'n onbestuurde verskafferprofiel kan terselfdertyd op een foon sit.

Kyk na die bewyse in plaas van die skermkiekie

Skermkiekies is die swakste bewys wat daar is, want die Instellings-groepering verander tussen uitgawes. 'n Bestuurde profiel noem sy eie loonvragtipe: 'n ingeboude profiel verklaar 'n VPN-tipe soos IKEv2 of IPsec, terwyl 'n verskafferprofiel 'n subtipe dra wat die verskaffer se bundelidentifiseerder noem. Dit is op die toestel voor jou nagegaanbaar, en dit oorleef die volgende herontwerp.

Vir die program self beantwoord die klas wat gebruik word dieselfde vraag van die ander kant: konfigurasie-objekte van die Persoonlike VPN-API, of 'n verskafferbestuurder en sy uitbreiding.

Kies dan volgens wat die operateur werklik lewer. Waar 'n versoenbare inheemse profiel bestaan, het die ingeboude pad minder bewegende dele en een ding minder om op te dateer. Waar die diens 'n protokol nodig het wat iOS nie verskaf nie, is 'n verskafferprogram die enigste opsie en word sy vrystellingsritme deel van jou risiko.

Hou die rekord by die verbinding

Heg magtiging en hulpbronbeleid aan die verbindingsrekord eerder as aan die program, sodat 'n herinstallasie nie die magtigingsmodel saamneem nie. Daardie rekord is ook wat 'n ondersteuningsingenieur nodig het wanneer die tunnel opkom en niks anders werk nie.

Die vraag wat op die end werd is om te vra, is nie watter model beter is nie. Dit is watter model jou operateur ondersteun, en watter een jy om twee in die oggend kan ontfout met die gereedskap wat jy werklik het.

Verwante artikels