Pag-export ng VPN sa Android: ano talaga ang nalilipat sa bagong telepono

Ang pag-export ng profile ng VPN mula sa Android ay parang hakbang sa backup, at ang menu na nag-aalok nito ay walang ginagawa upang itama ang impresyong iyon. Ang natitira sa iyo ay isang input para sa parser, isang key na maaaring hindi na ibalik ng operating system, at isang awtorisasyong inilabas para sa partikular na teleponong iyon. Paghiwalayin ang tatlong ito at lalabas ang kapaki-pakinabang na tanong: aling bahagi ang kulang pa sa bagong device?

Ang file ang madaling bahagi. Ang dalawa pa ang magpapasya kung gagana ang paglilipat.

Ano talaga ang nilalaman ng na-export na profile

Buksan ang file sa isang text editor bago ito pagkatiwalaan. Ang OpenVPN profile ay isang maliit na wikang pang-configuration: remote, proto, data-ciphers, at kadalasan mga inline na bloke na <ca>, <cert>, <key> o <tls-crypt> na ibinibigay ng client sa TLS stack nito. Ang WireGuard config ay mas patag: may PrivateKey at Address sa [Interface], pagkatapos ay isang [Peer] bawat endpoint na may PublicKey, AllowedIPs at Endpoint. Ang IKEv2 ay dumarating bilang .mobileconfig na may mga diksyunaryo ng payload sa halip na mga bloke ng key.

Wala sa mga tekstong iyon ang credential sa sarili nito. Ang credential ay ang pribadong key, at bawat format ay idinidikit ito sa loob o tumuturo sa isang alias na nareresolba lamang sa loob ng client na gumawa nito.

Saan talaga nakatira ang key sa Android

Iniimbak ng Android ang data ng app sa ilalim ng /data/data/<package>, na mababasa lamang ng UID ng app na iyon. Walang sinusuportahang paraan upang kopyahin ang pribadong direktoryo ng ibang app mula sa teleponong walang root, at ang adb backup ay tumigil na maging pangkalahatang sagot matapos itong ihinto ng Android 12 at magsimulang magdeklara ang mga client ng allowBackup="false". Kaya ang pag-export mula sa isang Android client ay nangangahulugan ng ipinapatupad ng client na iyon, hindi kopya ng file system.

Ang layer ng pagkakakilanlan ay nasa ilalim ng app. Kung nag-import ang isang client ng iyong key sa Android Keystore, doon nililikha o binalot ang materyal, at ang mga susunod na export ay maaaring magdala ng reference sa isang alias ng Keystore sa halip na bytes. Ang mga key na sinusuportahan ng hardware ay ginawa upang kahit ang nagmamay-ari ng app ay hindi ito mabasa, gaya ng inilalarawan ng Keystore documentation, kaya ang profile na tumuturo sa alias na iyon ay malinis na na-import sa parehong telepono at nabibigo sa lahat ng ibang lugar.

Hindi iyon sirang export. Iyon ang katangiang hiniling mula sa platform.

Ano ang hindi madadala ng profile

Ihambing ang mga bagay sa tatanggapin ng destinasyon:

Dalawang hilera ang nagdudulot ng karamihan ng kalituhan. Ang key na ginawa sa device at minarkahang hindi maaaring i-export ay talagang nawawala kasama ng data ng app, kaya ang kapalit ay bagong key at certificate na inilabas para dito. Ang session token na kinopya sa bagong telepono ay karaniwang namamatay sa unang refresh, na mukhang nabigong import.

Ang import ay isang pag-parse, pagkatapos ay isang kahilingan ng pahintulot

Sa panig ng tumatanggap, ang import ay isang pag-parse na sinusundan ng commit. Binabasa ng client ang configuration, tinitingnan kung umiiral ang bawat bloke na tinutukoy, pagkatapos ay isinusulat ang kahulugan ng tunnel sa sarili nitong sandbox, kaya ang file na pinili mo mula sa Mga Download ay hindi ang kumokonekta pagkatapos.

Pagkatapos ay dumarating ang hakbang ng awtorisasyon na walang file na makalalampas. Inaatasan ng Android ang app na tawagin ang VpnService.prepare() at makuha ang pahintulot mo bago ito makapagtatag ng tunnel, kaya ang bagong import na profile ay nagpapakita pa rin ng dialog ng system nang isang beses. Pagkatapos ay tahasang itinatayo ang tunnel sa pamamagitan ng addAddress, addRoute, addDnsServer at addAllowedApplication o addDisallowedApplication para sa routing bawat app. Wala sa mga ito ang ipinahihiwatig ng isang endpoint, kaya ang parehong profile ay maaaring makabuo ng ibang epektibong set ng ruta sa dalawang client.

Ang mga setup na nakabatay sa certificate ay nagdaragdag ng isa pang sanga. Kapag naglabas ang server ng certificate para sa isang partikular na device, gaya ng ginagawa ng MDM at SCEP enrollment, ang muling paggamit nito sa pangalawang telepono ay gumagana hanggang sa ipatupad ng server ang isang sesyon bawat pagkakakilanlan, o nabibigo ito sa TLS handshake. Suriin ang patakaran ng naglalabas bago magplano ng muling paggamit.

I-verify ang bagong device bago i-retiro ang luma

Panatilihing nakakonekta ang lumang telepono hanggang makapasa ang bago ng mas mabuti kaysa berdeng icon. Kumpirmahin ang exit address mula sa bagong device at ang DNS resolver na aktwal na ginamit nito. Kung mahalaga ang split tunneling, ilunsad ang app na dapat lumampas sa tunnel at isa na hindi dapat, pagkatapos ay tingnan kung alin ang nakakarating sa iyong ISP.

Isang pagsusuri ang magpapasya sa exit address. Buksan ang https://ifconfig.me sa browser ng telepono, pagkatapos ay patakbuhin ang curl -s https://ifconfig.me mula sa laptop sa parehong Wi-Fi at ihambing ang dalawang sagot sa address na itinalaga ng iyong provider.

Saka lamang i-retiro ang lumang pagkakakilanlan, at gawin ito sa pamamagitan ng naglalabas: bawiin ang certificate o alisin ang device sa account. Ang pagbura ng file mula sa Mga Download ay walang tinatapos, dahil ang dalawang device na may parehong certificate ay magkamukha sa log ng server.

Kung ang export ay lumabas na hindi portable, ang solusyon ay bagong enrollment at hindi pampublikong bundle ng configuration. Humingi ng profile para sa pangalawang device, o gumawa ng key pair sa bagong telepono at isumite ang CSR; mas mabagal, at iyon ang landas na sinusuportahan ng naglalabas.

Patakbuhin ang checklist bago burahin ang anuman: kumokonekta ang bagong device, tugma ang exit address at DNS, ang saklaw bawat app ay gaya ng nilayon mo, binawi ang lumang pagkakakilanlan, at anumang config file na itinago mo ay nasa naka-encrypt na storage.