Извоз на VPN од Android: што навистина се пренесува на нов телефон

Извозот на VPN профил од Android изгледа како чекор за резервна копија, а менито што го нуди не прави ништо за да го поправи тој впечаток. Она што го носите со себе е влез за parser, клуч што оперативниот систем можеби никогаш нема да го врати и авторизација издадена токму на тој телефон. Одделете ги тие три и се појавува корисното прашање: кој дел сè уште недостасува на новиот уред?

Датотеката е лесниот дел. Другите две одлучуваат дали миграцијата ќе работи.

Што всушност содржи извезениот профил

Отворете ја датотеката во текстуален уредувач пред да ѝ верувате. Профилот на OpenVPN е мал конфигурациски јазик: remote, proto, data-ciphers и често вградени блокови <ca>, <cert>, <key> или <tls-crypt> што клиентот ги предава на својот TLS стек. Конфигурацијата на WireGuard е порамна: [Interface] содржи PrivateKey и Address, потоа по еден [Peer] за секоја крајна точка со PublicKey, AllowedIPs и Endpoint. IKEv2 доаѓа како .mobileconfig со речници на полезен товар наместо блокови со клучеви.

Ниту еден од тие текстови не е уверение сам по себе. Уверението е приватниот клуч, и секој формат или го вметнува внатре, или упатува на алијас што се разрешува само во клиентот што го создал.

Каде клучот навистина живее на Android

Android ги чува податоците на апликациите под /data/data/<package>, читливи само за UID на таа апликација. Нема поддржан начин да се копира приватниот директориум на друга апликација од телефон без root, а adb backup престана да биде општ одговор откако Android 12 го укина и клиентите почнаа да декларираат allowBackup="false". Затоа извозот од Android клиент значи она што тој клиент го спроведува, не копија на датотечниот систем.

Слојот на идентитет лежи под апликацијата. Ако клиент го увезе вашиот клуч во Android Keystore, материјалот се генерира или обвиткува таму, а подоцнежните извози можат да носат референца на Keystore алијас наместо бајтите. Клучевите со хардверска поддршка се изградени така што дури ни апликацијата сопственик не може да ги прочита, како што опишува Keystore documentation, па профилот што упатува на тој алијас се увезува чисто на истиот телефон и не успева насекаде другаде.

Тоа не е расипан извоз. Тоа е својството што платформата беше замолена да го обезбеди.

Што профилот не може да пренесе

Поставете ги објектите наспроти она што ќе го прифати одредиштето:

Два реда предизвикуваат најголем дел од забуната. Клуч генериран на уредот и означен како неизвезлив навистина исчезнува со податоците на апликацијата, па замената е нов клуч плус сертификат издаден за него. Сесиски токен копиран на нов телефон обично умира при првото освежување, што изгледа како неуспешен увоз.

Увозот е парсирање, потоа барање за согласност

На страната на примачот, увозот е парсирање по кое следи запишување. Клиентот ја чита конфигурацијата, проверува дали постои секој наведен блок, потоа ја запишува дефиницијата на тунелот во својот песочник, поради што датотеката што ја избравте од Преземања не е онаа што се поврзува потоа.

Потоа доаѓа чекор за авторизација што ниту една датотека не може да го прескокне. Android бара апликацијата да го повика VpnService.prepare() и да ја добие вашата согласност пред да може да воспостави тунел, па новоувезениот профил сè уште еднаш го прикажува системскиот дијалог. Потоа тунелот се гради експлицитно преку addAddress, addRoute, addDnsServer и addAllowedApplication или addDisallowedApplication за насочување по апликации. Ниту едно од тоа не произлегува од крајна точка, па истиот профил може да даде различен збир ефективни рути во два клиенти.

Поставките засновани на сертификати додаваат уште едно разгранување. Кога серверот издава сертификат на определен уред, како што прават MDM и запишувањето SCEP, неговото повторно користење на втор телефон или работи додека серверот не наложи една сесија по идентитет, или не успее при TLS ракувањето. Проверете ја политиката на издавачот пред да планирате повторно користење.

Проверете го новиот уред пред да го пензионирате стариот

Држете го стариот телефон поврзан додека новиот не помине нешто подобро од зелена икона. Потврдете ја излезната адреса од новиот уред и DNS резолверот што навистина го користел. Ако split tunneling е важно, стартувајте апликација што треба да го заобиколи тунелот и една што не треба, па видете која стигнува до вашиот давател.

Една проверка ја решава излезната адреса. Отворете https://ifconfig.me во прелистувачот на телефон, потоа извршете curl -s https://ifconfig.me од преносен компјутер на истиот Wi-Fi и споредете ги двата одговора со адресата што ја доделил вашиот давател.

Дури тогаш пензионирајте го стариот идентитет и тоа направете го преку издавачот: отповелете го сертификатот или отстранете го уредот од сметката. Бришењето датотека од Преземања не завршува ништо, бидејќи два уреда со ист сертификат изгледаат идентично во дневникот на серверот.

Ако извозот се покаже како непренослив, решението е нова регистрација, а не јавен конфигурациски пакет. Побарајте профил за втор уред или генерирајте го парот клучеви на новиот телефон и поднесете CSR; побавно е и тоа е патот што издавачот го поддржува.

Поминете ја контролната листа пред да избришете нешто: новиот уред се поврзува, излезната адреса и DNS се совпаѓаат, опфатот по апликации е како што сакавте, стариот идентитет е отповикан и секоја зачувана конфигурациска датотека е во шифриран простор.