Săptămâna trecută un coleg mi-a întins iPhone-ul lui cu două intrări VPN în Setări: una lăsată de o aplicație de furnizor, cealaltă dintr-un profil IKEv2 lipit de pe o pagină de asistență. Nu sunt versiuni concurente ale aceluiași lucru. O aplicație de furnizor este un container care poate purta propriul cod de tunel, în timp ce clientul integrat al Apple este un client IKEv2, configurat manual sau printr-un profil. Protocolul, gestionarea acreditărilor, controlul dispozitivului și recuperarea decid alegerea.

Aplicația și clientul nativ stau pe straturi diferite

Clientul VPN integrat al Apple este, în practică, un client IKEv2. Formularul manual mai listează L2TP peste IPsec și opțiunile Cisco IPsec, demult învechite, dar nu există niciun câmp de transport al furnizorului și niciun loc unde să lipești o configurație OpenVPN sau WireGuard. Fie completați un formular în Setări > General > VPN & Gestionarea dispozitivului, fie importați un profil cu o încărcătură VPN; suprafața este o adresă de server, două identități, o metodă de autentificare și reguli opționale la cerere.

O aplicație de furnizor lucrează cu un strat mai sus. Oferă un furnizor de tunel de pachete Network Extension, așa că codul protocolului și logica de rutare trăiesc în aplicație, iar iOS doar lasă pachetele să treacă. Unele aplicații implementează WireGuard sau OpenVPN, altele un transport ofuscat propriu, iar câteva instalează doar un profil IKEv2 și conduc clientul nativ în spatele unui ecran mai frumos. Ultimul grup este motivul pentru care alegerea aplicație versus profil este uneori falsă.

Consecința este practică: un fișier .ovpn sau WireGuard nu înlocuiește acele câmpuri, pentru că strângerea de mână este alt protocol.

Citiți încărcătura înainte de a compara funcții

Când profilul este IKEv2, cheile încărcăturii explică mai multe eșecuri decât orice comparație de funcții. Referința setărilor IKEv2 de la Apple documentează fiecare cheie; o încărcătură scurtată arată astfel:

<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>

Trei câmpuri poartă cea mai mare parte a greutății de diagnostic. RemoteIdentifier este numele pe care clientul îl așteaptă de la server, așa că o poartă din spatele NAT sau un balansator de sarcină al cărui certificat numește grupul în locul adresei eșuează chiar dacă adresa este corectă. LocalIdentifier este identitatea pe care serverul crede că o ai, iar la autentificarea prin certificat trebuie să corespundă identității asociate contului tău. ServerCertificateIssuerCommonName fixează autoritatea de certificare emitentă, așa că un profil poate eșua în ziua în care certificatul este reemis, fără ca vreun mesaj de eroare să menționeze certificate.

Dacă AuthenticationMethod este egal cu SharedSecret, serverul face autentificare de utilizator EAP, iar secretul primit este de fapt o acreditare de cont. Asta contează când un furnizor trimite două documente, unul pentru numele de utilizator și parolă și unul pentru un certificat, și doar unul corespunde cu ce ai importat.

Ce poate face aplicația și clientul nativ nu

Alegerea protocolului este avantajul evident. Dacă serverul tău vorbește WireGuard sau OpenVPN, aplicația este singurul client iOS care îl poate folosi, iar editarea formularului nativ nu îl va negocia. O aplicație poate implementa și tunel divizat pe destinație sau aplicație, propria gestionare DNS, blocare în stil kill switch, selectarea serverului și reconectare reglată pentru propria rețea.

Prețul este software pe care nu l-ai auditat, rulând cu privilegiile unei extensii de rețea. Calitatea variază mai mult decât sugerează fișele magazinului: o aplicație se reconectează curat, în timp ce alta scurge câteva secunde după o schimbare de rețea, iar kill switch-ul din aplicație este o funcție a acelei aplicații, nu a iOS. Pe un dispozitiv gestionat, verifică mai întâi lista aprobată.

Ce face corect profilul IKEv2 integrat

Mai puține piese mobile este întregul argument. Clientul IKEv2 și stiva sa IPsec vin cu sistemul de operare, așa că nu există extensie care să cadă, nici proces per aplicație de menținut în viață și nici ciclu de actualizări terțe între tine și un tunel funcțional. Un profil poate fi și blocat: pe un dispozitiv supravegheat utilizatorul nu poate elimina ce a instalat managementul, iar Always On VPN, care se reconectează pe orice rețea fără comutator de utilizator, există doar în acea formă supravegheată și gestionată prin profil.

Ce nu oferă calea integrată este flexibilitatea. Nu există VPN per aplicație fără aplicații gestionate, nici kill switch pentru utilizator, nici transport care să arate ca HTTPS într-o rețea care blochează IPsec. În rețelele de hotel care aruncă UDP 500 și 4500, IKEv2 integrat nu are alternativă.

Un tabel de decizie care rezolvă majoritatea cazurilor

În practică, întrebarea protocolului decide majoritatea cazurilor înainte ca funcțiile să conteze.

What you were givenDevice situationWhat to use
An .ovpn or WireGuard configPersonal phoneProvider app; the native form cannot load it
IKEv2 host plus CA namePersonal or managedProfile, or the app's own IKEv2 mode
IKEv2 with username and secretPersonal phoneEither; the profile is simpler if you never switch servers
A management-installed profileSupervised, MDMNative client; do not add a second app entry
A per-app tunnelling requirementPersonal phoneApp, or accept a full tunnel; iOS cannot split by app without management
IPsec blocked on your main networkAnyApp with a transport that survives the block

Două rânduri merită o a doua privire. Cerința per aplicație pe un telefon personal este cazul pe care oamenii îl citesc greșit: setarea există în iOS, dar este condusă de management, așa că un dispozitiv negestionat nu o va oferi. O rețea blocată nu este un motiv să nu ai încredere în IKEv2; este motivul pentru care există aplicația furnizorului.

Verificați alegerea cu o singură încercare

Testați modurile de eșec, nu butonul de conectare. Conectați-vă o dată, confirmați că apare indicatorul VPN, apoi deschideți o pagină care vă returnează adresa publică și comparați-o cu cea anterioară. Treceți de la Wi-Fi la date mobile fără să atingeți VPN-ul și urmăriți reconectarea, apoi treceți telefonul prin modul avion. Reporniți și vedeți dacă tunelul revine singur: un profil cu OnDemandEnabled ar trebui, în timp ce multe aplicații trebuie deschise mai întâi.

Când nu revine, împărțiți eșecul după existența unui tunel. Lipsa indicatorului VPN înseamnă că tunelul nu a urcat niciodată: fie strângerea de mână a eșuat la RemoteIdentifier, la CA-ul fixat sau la o acreditare, fie conexiunea nu a fost niciodată încercată pentru că regula la cerere nu se potrivea și nicio aplicație nu a pornit-o. Un indicator cu trafic eșuat înseamnă rutare, DNS sau politică pe server, iar reinstalarea clientului nu atinge nimic din asta.

O listă scurtă ca dispozitivul să fie explicabil pentru următoarea persoană:

  • o singură intrare VPN, nu două;
  • profilul sau aplicația numite după serverul la care se conectează;
  • valorile identității notate unde le poți găsi.

Începeți cu rândul protocolului din tabel și opriți-vă acolo dacă răspunde la întrebare.

Articole similare