Експорт VPN на Android: що насправді переноситься на новий телефон

Експорт профілю VPN з Android сприймається як крок резервного копіювання, і меню, яке його пропонує, нічого не робить, щоб виправити це враження. У вас залишаються вхідні дані для парсера, ключ, який операційна система може ніколи не повернути, і авторизація, видана саме цьому телефону. Розділіть ці три речі, і з'явиться корисне питання: якої частини ще немає на новому пристрої?

Файл — це проста частина. Дві інші вирішують, чи спрацює перенесення.

Що насправді містить експортований профіль

Відкрийте файл у текстовому редакторі, перш ніж йому довіряти. Профіль 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 збігаються, охоплення за застосунками таке, як ви задумали, стара ідентичність відкликана, а будь-який збережений файл конфігурації лежить у зашифрованому сховищі.