VPN profila eksportēšana no Android šķiet kā dublēšanas solis, un izvēlne, kas to piedāvā, neko nedara, lai šo iespaidu labotu. Jums paliek parsera ievade, atslēga, ko operētājsistēma, iespējams, nekad neatgriezīs, un autorizācija, kas izsniegta tieši šim telefonam. Atdaliet šos trīs, un parādās noderīgais jautājums: kura daļa jaunajā ierīcē vēl trūkst?

Fails ir vieglā daļa. Pārējie divi izlemj, vai migrācija darbosies.

Ko patiešām satur eksportētais profils

Atveriet failu teksta redaktorā, pirms tam uzticaties. OpenVPN profils ir maza konfigurācijas valoda: remote, proto, data-ciphers un bieži iekļauti <ca>, <cert>, <key> vai <tls-crypt> bloki, ko klients nodod savai TLS kopai. WireGuard konfigurācija ir plakanāka: [Interface] satur PrivateKey un Address, tad pa vienam [Peer] katram galapunktam ar PublicKey, AllowedIPs un Endpoint. IKEv2 nāk kā .mobileconfig ar lietderīgās slodzes vārdnīcām, nevis atslēgu blokiem.

Neviens no šiem tekstiem pats par sevi nav akreditācijas dati. Akreditācijas dati ir privātā atslēga, un katrs formāts to vai nu ielīmē iekšpusē, vai norāda uz aizstājvārdu, kas atrisinās tikai tā klienta iekšienē, kas to izveidoja.

Kur atslēga patiešām dzīvo Android

Android glabā lietotņu datus zem /data/data/<package>, ko lasīt var tikai šīs lietotnes UID. Nav atbalstīta veida, kā no telefona bez root kopēt citas lietotnes privāto direktoriju, un adb backup pārstāja būt vispārēja atbilde pēc tam, kad Android 12 to atcēla un klienti sāka deklarēt allowBackup="false". Tāpēc eksports no Android klienta nozīmē to, ko šis klients ievieš, nevis failu sistēmas kopiju.

Identitātes slānis atrodas zem lietotnes. Ja klients importēja jūsu atslēgu Android Keystore, materiāls tur tiek ģenerēts vai ietīts, un vēlāki eksporti var saturēt atsauci uz Keystore aizstājvārdu, nevis baitiem. Aparatūras aizsargātās atslēgas ir veidotas tā, ka pat tās īpašniece lietotne nevar tās nolasīt, kā apraksta Keystore documentation, tāpēc profils, kas norāda uz šo aizstājvārdu, tiek tīri importēts tajā pašā telefonā un visur citur neizdodas.

Tas nav salauzts eksports. Tā ir īpašība, ko platformai lūdza nodrošināt.

Ko profils nevar pārnest

Salīdziniet objektus ar to, ko uztvērējs pieņems:

ObjektsPāriet?Kāpēc
Protokols un galapunktsJā, ja galamērķa klients to atbalstaVienkāršs teksts profilā
CA sertifikāts un resursdatora vārda pārbaudeParastiPublisks materiāls, bet resursdatora vārdam joprojām jāatbilst sertifikātam
Klienta sertifikātsJā, ja vien tas nav piesaistīts konkrētai ierīceiSertifikāti ir pārnēsājami; izsniedzējs izlemj, cik ierīcēs var izmantot vienu
Privātā atslēgaTikai ja tā ģenerēta ārpus KeystoreAparatūras aizsargātās atslēgas nevar eksportēt, tikai aizstāt
Konts, MFA, SSO sesijaNēMarķieri beidzas un paliek piesaistīti ierīcei, kas tos ieguva
Maršruti, DNS un lietotņu tvērumsTikai kā konfigurācijas tekstsAndroid tos piemēro savienojuma laikā caur VpnService.Builder
Sad alītā tuneļa lietotņu sarakstsRetiPakotņu nosaukumi atšķiras starp ierīcēm, un saraksts ir klienta stāvoklis

Divas rindas rada lielāko daļu apjukumu. Ierīcē ģenerēta un kā neeksportējama atzīmēta atslēga patiešām pazūd kopā ar lietotnes datiem, tāpēc aizstājējs ir jauna atslēga un tai izsniegts sertifikāts. Uz jaunu telefonu nokopēts sesijas marķieris parasti mirst pirmajā atjauninājumā, kas izskatās kā neizdevies imports.

Imports ir parsēšana, pēc tam piekrišanas pieprasījums

Uzņēmējā pusē imports ir parsēšana, kurai seko ierakstīšana. Klients nolasa konfigurāciju, pārbauda, vai eksistē katrs minētais bloks, un pēc tam ieraksta tuneļa definīciju savā smilškastē, tāpēc fails, ko izvēlējāties Lejupielādēs, nav tas, kas pēc tam pieslēdzas.

Tad nāk autorizācijas solis, ko neviens fails nevar izlaist. Android pieprasa, lai lietotne izsauktu VpnService.prepare() un saņemtu jūsu piekrišanu pirms tuneļa izveides, tāpēc tikko importēts profils tomēr vienu reizi parāda sistēmas dialogu. Pēc tam tunelis tiek skaidri būvēts, izmantojot addAddress, addRoute, addDnsServer un addAllowedApplication vai addDisallowedApplication maršrutēšanai pa lietotnēm. Neviens no tiem neizriet no galapunkta, tāpēc viens un tas pats profils divos klientos var radīt atšķirīgu faktisko maršrutu kopu.

Sertifikātos balstītas konfigurācijas pievieno vēl vienu atzaru. Kad serveris izsniedz sertifikātu konkrētai ierīcei, kā to dara MDM un SCEP reģistrācija, tā atkārtota izmantošana otrajā telefonā vai nu darbojas, līdz serveris pieprasa vienu sesiju uz identitāti, vai neizdodas TLS rokas paspiešanā. Pārbaudiet izsniedzēja politiku pirms atkārtotas izmantošanas plānošanas.

Pārbaudiet jauno ierīci pirms vecās izņemšanas

Turiet veco telefonu pievienotu, līdz jaunais ir izturējis ko labāku par zaļu ikonu. Apstipriniet izejas adresi no jaunās ierīces un DNS risinātāju, ko tā faktiski izmantoja. Ja split tunneling ir svarīgs, palaidiet lietotni, kurai vajadzētu apiet tuneli, un vienu, kurai nevajadzētu, un paskatieties, kura sasniedz jūsu pakalpojumu sniedzēju.

Viena pārbaude nosaka izejas adresi. Atveriet https://ifconfig.me telefona pārlūkā, pēc tam palaidiet curl -s https://ifconfig.me no portatīvā datora tajā pašā Wi-Fi un salīdziniet abas atbildes ar adresi, ko piešķīris jūsu pakalpojumu sniedzējs.

Tikai tad izņemiet veco identitāti, un dariet to caur izsniedzēju: atsauciet sertifikātu vai izņemiet ierīci no konta. Faila dzēšana no Lejupielādēm neko nebeidz, jo divas ierīces ar vienu sertifikātu servera žurnālā izskatās identiskas.

Ja eksports izrādās nepārnēsājams, risinājums ir jauna reģistrācija, nevis publiska konfigurācijas pakotne. Pieprasiet profilu otrajai ierīcei vai ģenerējiet atslēgu pāri jaunajā telefonā un iesniedziet CSR; lēnāk, un tas ir ceļš, ko atbalsta izsniedzējs.

Izejiet kontrolsarakstu pirms kaut ko dzēšat: jaunā ierīce pieslēdzas, izejas adrese un DNS sakrīt, tvērums pa lietotnēm ir tāds, kā vēlējāties, vecā identitāte ir atsaukta, un jebkurš saglabātais konfigurācijas fails atrodas šifrētā glabātavā.

Saistītie raksti