App ng VPN o built-in na IKEv2 sa iPhone: paano pumili

Noong nakaraang linggo, iniabot sa akin ng isang katrabaho ang kanyang iPhone na may dalawang entry ng VPN sa Settings: isang iniwan ng app ng provider, isa mula sa profile ng IKEv2 na na-paste mula sa pahina ng suporta. Hindi sila magkaribal na bersyon ng iisang bagay. Ang app ng provider ay isang lalagyang maaaring magdala ng sarili nitong code ng tunel, habang ang built-in na kliyente ng Apple ay kliyenteng IKEv2, na kinokonfigura nang manwal o sa pamamagitan ng profile. Ang protocol, paghawak ng kredensyal, kontrol sa device at pagbawi ang nagtatakda ng pagpili.

Ang app at ang native na kliyente ay nasa magkaibang antas

Ang built-in na kliyenteng VPN ng Apple sa praktika ay kliyenteng IKEv2. Nakalista pa rin sa manwal na form ang lipas nang L2TP sa ibabaw ng IPsec at mga opsyon ng Cisco IPsec, ngunit walang field para sa transport ng provider at walang lugar na mapag-paste ng konfigurasyon ng OpenVPN o WireGuard. Pupunan mo ang form sa Settings > Pangkalahatan > VPN & Pamamahala ng Device o mag-aangkat ka ng profile na may payload ng VPN; ang ibabaw ay address ng server, dalawang pagkakakilanlan, isang paraan ng pagpapatotoo at opsyonal na mga tuntunin kapag hiniling.

Ang app ng provider ay gumagana nang isang antas pataas. Nagdadala ito ng provider ng packet tunnel ng Network Extension, kaya ang code ng protocol at lohika ng routing ay nasa app at ang iOS ay nagpapasa lang ng packet. May mga app na gumagawa ng WireGuard o OpenVPN, may gumagawa ng sariling nakatagong transport, at iilan ang nag-iinstall lang ng profile ng IKEv2 at nagmamaneho ng native na kliyente sa likod ng mas magandang screen. Ang huling grupong ito ang dahilan kung bakit paminsan-minsan ay huwad na pagpili ang app kumpara sa profile.

Praktikal ang kahihinatnan: ang file na .ovpn o WireGuard ay hindi kapalit ng mga field na iyon, dahil ibang protocol ang handshake.

Basahin ang payload bago ihambing ang mga feature

Kapag IKEv2 ang profile, mas maraming pagkabigo ang ipinapaliwanag ng mga key ng payload kaysa sa anumang paghahambing ng feature. Ang sanggunian ng mga setting ng IKEv2 ng Apple ay nagdodokumento ng bawat key; ganito ang hitsura ng pinutol na payload:

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

Tatlong field ang may pinakamalaking bigat sa diyagnosis. Ang RemoteIdentifier ay ang pangalang inaasahan ng kliyente mula sa server, kaya ang gateway sa likod ng NAT o ang load balancer na ang sertipiko ay nagpangalan ng pool sa halip na address ay nabibigo kahit tama ang address. Ang LocalIdentifier ay ang pagkakakilanlang inaakala ng server na ikaw, at sa pagpapatotoo ng sertipiko dapat itong tumugma sa pagkakakilanlang nakamapa sa iyong account. Ang ServerCertificateIssuerCommonName ay nagpipin ng nag-isyung CA, kaya maaaring mabigo ang profile sa araw na muling ilabas ang sertipiko, nang walang anumang mensahe ng error na nagbabanggit ng mga sertipiko.

Kung ang AuthenticationMethod ay katumbas ng SharedSecret, gumagawa ang server ng pagpapatotoo ng user na EAP at ang lihim na ibinigay sa iyo ay talagang kredensyal ng account. Mahalaga ito kapag may dalawang dokumentong ipinadala ang provider, isa para sa username at password at isa para sa sertipiko, at isa lang ang tumutugma sa inangkat mo.

Ano ang kaya ng app at hindi kaya ng native na kliyente

Ang pagpili ng protocol ang halatang bentahe. Kung ang server mo ay nagsasalita ng WireGuard o OpenVPN, ang app ang tanging kliyenteng iOS na makakagamit nito, at hindi ito ipakikipagkasundo ng pag-edit sa native na form. Maaari ring ipatupad ng app ang split tunnelling ayon sa destinasyon o app, sariling paghawak ng DNS, pagharang na parang kill switch, pagpili ng server at muling pagkonekta na nakaayon sa sarili nitong network.

Ang halaga ay software na hindi mo inaudit, tumatakbo nang may pribilehiyo ng network extension. Mas malaki ang pagkakaiba ng kalidad kaysa sa ipinahihiwatig ng mga card sa tindahan: may app na malinis na muling kumokonekta habang ang isa ay tumutulo nang ilang segundo pagkatapos magbago ang network, at ang kill switch sa loob ng app ay feature ng app na iyon, hindi ng iOS. Sa pinamamahalang device, tingnan muna ang aprubadong listahan.

Ano ang ginagawa nang tama ng built-in na profile ng IKEv2

Mas kaunting gumagalaw na bahagi ang buong argumento. Ang kliyenteng IKEv2 at ang stack nitong IPsec ay kasama ng operating system, kaya walang extension na maaaring bumagsak, walang proseso kada app na kailangang buhayin, at walang ikot ng update ng third party sa pagitan mo at ng gumaganang tunel. Maaari ring i-lock ang profile: sa device na pinangangasiwaan, hindi maaaring alisin ng user ang inilagay ng pamamahala, at ang Always On VPN, na muling kumokonekta sa anumang network nang walang switch ng user, ay umiiral lamang sa pinangangasiwaan at pinamamahalaan ng profile na anyo nito.

Ang hindi ibinibigay ng built-in na landas ay kakayahang umangkop. Walang VPN kada app kung walang pinamamahalang app, walang kill switch para sa user, at walang transport na mukhang HTTPS sa network na humaharang sa IPsec. Sa mga network ng hotel na nagtatapon ng UDP 500 at 4500, walang reserbang landas ang built-in na IKEv2.

Isang talahanayan ng desisyon na sumasagot sa karamihan ng kaso

Sa praktika, ang tanong ng protocol ang nagtatakda sa karamihan ng kaso bago maging mahalaga ang mga feature.

Dalawang hilera ang dapat tingnan muli. Ang pangangailangan kada app sa personal na telepono ang kasong maling binabasa ng mga tao: nasa iOS ang setting ngunit pinapatakbo ito ng pamamahala, kaya hindi ito iaalok ng device na hindi pinamamahalaan. Ang harang na network ay hindi dahilan para hindi pagkatiwalaan ang IKEv2; iyon ang dahilan kung bakit may app ang provider.

I-verify ang pagpili sa isang pagsubok

Subukan ang mga mode ng pagkabigo, hindi ang pindutan ng konekta. Kumonekta nang isang beses, tiyakin na lumilitaw ang tagapagpahiwatig ng VPN, pagkatapos buksan ang pahinang nagbabalik ng iyong pampublikong address at ihambing ito sa nauna. Lumipat mula Wi-Fi patungong mobile data nang hindi hinahawakan ang VPN at panoorin ang muling pagkonekta, pagkatapos ay ipadaan ang telepono sa airplane mode. I-restart at tingnan kung kusang bumabalik ang tunel: ang profile na may OnDemandEnabled ay dapat bumalik, habang maraming app ay kailangang buksan muna.

Kapag hindi ito bumalik, paghiwalayin ang pagkabigo ayon sa kung may tunel man. Walang tagapagpahiwatig ng VPN ay nangangahulugang hindi kailanman umangat ang tunel: alinman sa nabigo ang handshake sa RemoteIdentifier, sa naka-pin na CA o sa kredensyal, o hindi kailanman sinubukan ang koneksyon dahil hindi tumugma ang tuntunin kapag hiniling at walang app na nagpasimula nito. May tagapagpahiwatig ngunit nabibigo ang trapiko ay nangangahulugang routing, DNS o patakaran sa panig ng server, at ang muling pag-install ng kliyente ay walang hinahawakang anuman sa mga iyon.

Isang maikling listahan upang maipaliwanag ang device sa susunod na tao:

• isang entry ng VPN, hindi dalawa;
• pinangalanan ang profile o app sa server na kinokonektahan nito;
• nakasulat ang mga halaga ng pagkakakilanlan sa lugar na mahahanap mo.

Magsimula sa hilera ng protocol sa talahanayan, at huminto roon kung sinasagot nito ang tanong.