Javën e kaluar një koleg më dha iPhone-in e tij me dy zëra VPN në Cilësimet: njëri i lënë nga një aplikacion ofruesi, tjetri nga një profil IKEv2 i ngjitur nga një faqe mbështetjeje. Këto nuk janë versione konkurruese të së njëjtës gjë. Aplikacioni i ofruesit është një kontejner që mund të mbajë kodin e vet të tunelit, ndërsa klienti i integruar i Apple është një klient IKEv2, i konfiguruar me dorë ose me profil. Protokolli, trajtimi i kredencialeve, kontrolli i pajisjes dhe rikuperimi përcaktojnë zgjedhjen.

Aplikacioni dhe klienti vendas qëndrojnë në shtresa të ndryshme

Klienti VPN i integruar i Apple është në praktikë një klient IKEv2. Formulari manual vazhdon të listojë L2TP mbi IPsec dhe opsionet Cisco IPsec të vjetruara, por nuk ka fushë transporti të ofruesit dhe asnjë vend për të ngjitur një konfigurim OpenVPN ose WireGuard. Ose plotësoni një formular te Cilësimet > Të përgjithshme > VPN & Menaxhimi i pajisjes, ose importoni një profil me ngarkesë VPN; sipërfaqja është një adresë serveri, dy identitete, një metodë vërtetimi dhe rregulla opsionale sipas kërkesës.

Aplikacioni i ofruesit punon një shtresë më lart. Ai ofron një ofrues tuneli paketash Network Extension, kështu që kodi i protokollit dhe logjika e rrugëtimit jetojnë në aplikacion dhe iOS vetëm i kalon paketat. Disa aplikacione zbatojnë WireGuard ose OpenVPN, të tjerë një transport të vetëm të maskuar, dhe disa thjesht instalojnë një profil IKEv2 dhe drejtojnë klientin vendas pas një ekrani më të bukur. Ky grup i fundit është arsyeja pse aplikacioni kundrejt profilit ndonjëherë është zgjedhje e rreme.

Pasoja është praktike: një skedar .ovpn ose WireGuard nuk i zëvendëson ato fusha, sepse shtrëngimi i duarve është protokoll tjetër.

Lexoni ngarkesën përpara se të krahasoni veçoritë

Kur profili është IKEv2, çelësat e ngarkesës shpjegojnë më shumë dështime sesa çdo krahasim veçorish. Referenca e cilësimeve të IKEv2 e Apple dokumenton çdo çelës; një ngarkesë e shkurtuar duket kështu:

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

Tre fusha mbajnë pjesën më të madhe të peshës diagnostikuese. RemoteIdentifier është emri që klienti pret nga serveri, prandaj një portë pas NAT ose një balancues ngarkese certifikata e të cilit emërton grupin në vend të adresës dështon edhe pse adresa është e saktë. LocalIdentifier është identiteti që serveri mendon se jeni, dhe me vërtetim me certifikatë duhet të përputhet me identitetin e lidhur me llogarinë tuaj. ServerCertificateIssuerCommonName fikson CA-në lëshuese, kështu që një profil mund të dështojë ditën që certifikata rilëshohet, pa asnjë mesazh gabimi që përmend certifikata.

Nëse AuthenticationMethod është e barabartë me SharedSecret, serveri po kryen vërtetim përdoruesi EAP dhe sekreti që ju dha është në fakt një kredencial llogarie. Kjo ka rëndësi kur një ofrues dërgon dy dokumente, një për emrin e përdoruesit dhe fjalëkalimin dhe një për një certifikatë, dhe vetëm një përputhet me atë që importuat.

Çfarë mund të bëjë aplikacioni dhe klienti vendas jo

Zgjedhja e protokollit është avantazhi i dukshëm. Nëse serveri juaj flet WireGuard ose OpenVPN, aplikacioni është klienti i vetëm iOS që mund ta përdorë, dhe redaktimi i formularit vendas nuk do ta negociojë atë. Aplikacioni gjithashtu mund të zbatojë tunel të ndarë sipas destinacionit ose aplikacionit, trajtimin e vet të DNS-së, bllokim në stilin e kill switch, zgjedhjen e serverit dhe rilidhje të përshtatur me rrjetin e vet.

Çmimi është software që nuk e keni audituar, që ekzekutohet me privilegjet e një shtese rrjeti. Cilësia ndryshon më shumë sesa sugjerojnë kartat e dyqanit: një aplikacion rilidhet pastër ndërsa një tjetër rrjedh për disa sekonda pas një ndryshimi rrjeti, dhe kill switch brenda aplikacionit është veçori e atij aplikacioni, jo e iOS. Në një pajisje të menaxhuar, kontrolloni fillimisht listën e miratuar.

Çfarë bën saktë profili IKEv2 i integruar

Më pak pjesë lëvizëse është i gjithë argumenti. Klienti IKEv2 dhe stivi i tij IPsec vijnë me sistemin operativ, kështu që nuk ka shtesë që mund të rrëzohet, as proces për çdo aplikacion që duhet mbajtur gjallë, as cikël përditësimi nga palë të treta midis jush dhe një tuneli që funksionon. Një profil gjithashtu mund të kyçet: në një pajisje të mbikëqyrur përdoruesi nuk mund të heqë atë që ka instaluar menaxhimi, dhe Always On VPN, që rilidhet në çdo rrjet pa çelës përdoruesi, ekziston vetëm në atë formë të mbikëqyrur e të menaxhuar me profil.

Ajo që rruga e integruar nuk ju jep është fleksibiliteti. Nuk ka VPN për çdo aplikacion pa aplikacione të menaxhuara, as kill switch për përdoruesin, as transport që duket si HTTPS në një rrjet që bllokon IPsec. Në rrjetet e hoteleve që hedhin UDP 500 dhe 4500, IKEv2 i integruar nuk ka rrugë rezervë.

Një tabelë vendimi që zgjidh shumicën e rasteve

Në praktikë pyetja e protokollit vendos shumicën e rasteve përpara se veçoritë të kenë rëndësi.

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

Dy rreshta meritojnë një vështrim të dytë. Kërkesa për çdo aplikacion në një telefon personal është rasti që njerëzit lexojnë gabim: cilësimi ekziston në iOS por drejtohet nga menaxhimi, prandaj një pajisje e pamenaxhuar nuk do ta ofrojë. Një rrjet i bllokuar nuk është arsye për të mos i besuar IKEv2; është arsyeja pse ekziston aplikacioni i ofruesit.

Verifikoni zgjedhjen me një provë

Provoni mënyrat e dështimit, jo butonin e lidhjes. Lidhuni një herë, konfirmoni që shfaqet treguesi VPN, më pas hapni një faqe që kthen adresën tuaj publike dhe krahasoni me atë të mëparshme. Kaloni nga Wi-Fi në të dhëna celulare pa prekur VPN dhe vëzhgoni rilidhjen, më pas kaloni telefonin në modalitetin avion. Rinisni dhe shikoni nëse tuneli kthehet vetë: një profil me OnDemandEnabled duhet, ndërsa shumë aplikacione duhet të hapen fillimisht.

Kur nuk kthehet, ndani dështimin sipas faktit nëse ekziston fare një tunel. Pa tregues VPN, tuneli nuk u ngrit kurrë: ose shtrëngimi i duarve dështoi në RemoteIdentifier, në CA-në e fiksuar ose në një kredencial, ose lidhja nuk u provua kurrë sepse rregulli sipas kërkesës nuk përputhej dhe asnjë aplikacion nuk e nisi. Tregues me trafik që dështon do të thotë rrugëtim, DNS ose politikë në anën e serverit, dhe riinstalimi i klientit nuk prek asnjë prej tyre.

Një listë e shkurtër që pajisja t'i shpjegohet personit tjetër:

  • një zë VPN, jo dy;
  • profili ose aplikacioni i emërtuar sipas serverit me të cilin lidhet;
  • vlerat e identitetit të shkruara atje ku mund t'i gjeni.

Filloni me rreshtin e protokollit në tabelë dhe ndaloni aty nëse përgjigjet pyetjes.

Artikuj të ngjashëm