Aplicació VPN o IKEv2 integrat a l’iPhone: com escollir
Una aplicació VPN per a iPhone i el client IKEv2 integrat resolen problemes diferents. Compareu primer el suport de protocols, l’autenticació, el control del dispositiu i la recuperació.
La setmana passada un company em va allargar el seu iPhone amb dues entrades VPN als Ajustos: una l’havia deixada una aplicació de proveïdor, l’altra venia d’un perfil IKEv2 enganxat d’una pàgina de suport. No són versions competidores de la mateixa cosa. Una aplicació de proveïdor és un contenidor que pot portar el seu propi codi de túnel, mentre que el client integrat d’Apple és un client IKEv2, configurat a mà o amb un perfil. El protocol, el tractament de credencials, el control del dispositiu i la recuperació decideixen l’elecció.
L’aplicació i el client natiu se situen en capes diferents
El client VPN integrat d’Apple és, en la pràctica, un client IKEv2. El formulari manual encara llista L2TP sobre IPsec i les opcions Cisco IPsec, ja obsoletes, però no hi ha cap camp de transport del proveïdor ni lloc on enganxar una configuració OpenVPN o WireGuard. O bé ompliu un formulari a Ajustos > General > VPN & Gestió del dispositiu, o bé importeu un perfil amb una càrrega VPN; la superfície és una adreça de servidor, dues identitats, un mètode d’autenticació i regles opcionals sota demanda.
Una aplicació de proveïdor treballa un nivell per sobre. Inclou un proveïdor de túnel de paquets de Network Extension, de manera que el codi del protocol i la lògica d’encaminament viuen a l’aplicació i l’iOS només deixa passar paquets. Algunes aplicacions implementen WireGuard o OpenVPN, d’altres un transport ofuscat propi, i unes poques només instal·len un perfil IKEv2 i controlen el client natiu rere una pantalla més agradable. Aquest darrer grup és la raó que aplicació contra perfil sigui de vegades una falsa tria.
La conseqüència és pràctica: un fitxer .ovpn o WireGuard no substitueix aquests camps, perquè l’encaixada de mans és un altre protocol.
Llegiu la càrrega abans de comparar funcions
Quan el perfil és IKEv2, les claus de la càrrega expliquen més fallades que qualsevol comparació de funcions. La referència de configuració d’IKEv2 d’Apple documenta cada clau; una càrrega retallada té aquest aspecte:
<key>VPNType</key><string>IKEv2</string>
<key>RemoteAddress</key><string>vpn.example.net</string>
<key>RemoteIdentifier</key><string>vpn.example.net</string>
<key>LocalIdentifier</key><string>[email protected]</string>
<key>AuthenticationMethod</key><string>Certificate</string>
<key>ServerCertificateIssuerCommonName</key><string>Example Issuing CA</string>
Tres camps porten la major part del pes diagnòstic. RemoteIdentifier és el nom que el client espera del servidor, així que una passarel·la darrere de NAT o un balancejador de càrrega el certificat del qual anomena el conjunt en lloc de l’adreça falla encara que l’adreça sigui correcta. LocalIdentifier és la identitat que el servidor creu que sou, i amb autenticació per certificat ha de coincidir amb la identitat associada al vostre compte. ServerCertificateIssuerCommonName fixa l’autoritat de certificació emissora, així que un perfil pot fallar el dia que es reemet el certificat, sense cap missatge d’error que esmenti certificats.
Si AuthenticationMethod val SharedSecret, el servidor fa autenticació d’usuari EAP i el secret que us van donar és en realitat una credencial de compte. Això importa quan un proveïdor envia dos documents, un per al nom d’usuari i la contrasenya i un per a un certificat, i només un coincideix amb el que heu importat.
Què pot fer l’aplicació que el client natiu no pot
L’elecció de protocol és l’avantatge evident. Si el vostre servidor parla WireGuard o OpenVPN, una aplicació és l’únic client iOS que el pot fer servir, i editar el formulari natiu no ho negociarà. Una aplicació també pot implementar túnel dividit per destinació o per aplicació, la seva pròpia gestió de DNS, un bloqueig a l’estil de kill switch, selecció de servidor i reconnexió ajustada a la seva pròpia xarxa.
El preu és programari que no heu auditat, executant-se amb els privilegis d’una extensió de xarxa. La qualitat varia més del que suggereixen les fitxes de la botiga: una aplicació es reconnecta netament mentre una altra vessa durant uns segons després d’un canvi de xarxa, i un kill switch dins de l’aplicació és una funció d’aquesta aplicació, no de l’iOS. En un dispositiu gestionat, comproveu primer la llista aprovada.
Què fa bé el perfil IKEv2 integrat
Menys peces mòbils és tot l’argument. El client IKEv2 i la seva pila IPsec venen amb el sistema, així que no hi ha cap extensió que es pugui penjar, ni cap procés per aplicació que calgui mantenir viu, ni cap cicle d’actualitzacions de tercers entre vosaltres i un túnel que funciona. Un perfil també es pot bloquejar: en un dispositiu supervisat l’usuari no pot treure el que ha instal·lat la gestió, i l’Always On VPN, que es reconnecta a qualsevol xarxa sense interruptor d’usuari, només existeix en aquesta forma supervisada i gestionada per perfil.
El que el camí integrat no us dona és flexibilitat. No hi ha VPN per aplicació sense aplicacions gestionades, ni kill switch per a l’usuari, ni un transport que sembli HTTPS en una xarxa que bloqueja IPsec. En xarxes d’hotel que descarten UDP 500 i 4500, l’IKEv2 integrat no té alternativa.
Una taula de decisió que resol la majoria de casos
A la pràctica, la pregunta del protocol decideix la majoria de casos abans que les funcions importin.
| What you were given | Device situation | What to use |
|---|---|---|
| An .ovpn or WireGuard config | Personal phone | Provider app; the native form cannot load it |
| IKEv2 host plus CA name | Personal or managed | Profile, or the app's own IKEv2 mode |
| IKEv2 with username and secret | Personal phone | Either; the profile is simpler if you never switch servers |
| A management-installed profile | Supervised, MDM | Native client; do not add a second app entry |
| A per-app tunnelling requirement | Personal phone | App, or accept a full tunnel; iOS cannot split by app without management |
| IPsec blocked on your main network | Any | App with a transport that survives the block |
Dues files mereixen una segona mirada. El requisit per aplicació en un telèfon personal és el cas que la gent llegeix malament: el paràmetre existeix a l’iOS però el controla la gestió, així que un dispositiu no gestionat no l’oferirà. Una xarxa bloquejada no és motiu per desconfiar de l’IKEv2; és la raó per la qual existeix l’aplicació del proveïdor.
Verifiqueu l’elecció amb una prova
Proveu les maneres de fallar, no el botó de connexió. Connecteu-vos un cop, confirmeu que apareix l’indicador de VPN, després obriu una pàgina que retorni la vostra adreça pública i compareu-la amb l’anterior. Passeu del Wi-Fi a les dades mòbils sense tocar la VPN i observeu si es reconnecta, després passeu el telèfon pel mode avió. Reinicieu i mireu si el túnel torna sol: un perfil amb OnDemandEnabled hauria de fer-ho, mentre que moltes aplicacions s’han d’obrir primer.
Quan no torna, separeu la fallada segons si hi ha cap túnel. Sense indicador de VPN, el túnel no s’ha aixecat mai: o l’encaixada de mans ha fallat a RemoteIdentifier, a l’autoritat de certificació fixada o en una credencial, o la connexió no s’ha provat mai perquè la regla sota demanda no coincidia i cap aplicació l’ha iniciada. Un indicador amb trànsit que falla vol dir encaminament, DNS o política del servidor, i reinstal·lar el client no toca res d’això.
Una llista curta per deixar el dispositiu explicable a la persona següent:
- una entrada VPN, no dues;
- el perfil o l’aplicació amb el nom del servidor al qual es connecta;
- els valors d’identitat escrits on els pugueu trobar.
Comenceu per la fila del protocol a la taula, i atureu-vos aquí si respon la pregunta.