Export VPN na Androidu: co se skutečně přenese do nového telefonu
Export VPN na Androidu přenáší nastavení a někdy klíč, ale nikdy autorizaci zařízení. Ověřte, co se skutečně přenese, než vymažete starý telefon.
Export profilu VPN z Androidu působí jako krok zálohy a nabídka, která ho nabízí, s tímto dojmem nic nedělá. Co vám zůstane, je vstup pro parser, klíč, který operační systém možná nikdy nevrátí, a autorizace vydaná právě tomuto telefonu. Oddělte tyto tři věci a objeví se užitečná otázka: která část na novém zařízení ještě chybí?
Soubor je ta snadná část. Další dvě rozhodují, zda migrace bude fungovat.
Co exportovaný profil skutečně obsahuje
Než mu uvěříte, otevřete soubor v textovém editoru. Profil OpenVPN je malý konfigurační jazyk: remote, proto, data-ciphers a často vložené bloky <ca>, <cert>, <key> nebo <tls-crypt>, které klient předává svému TLS zásobníku. Konfigurace WireGuard je plošší: [Interface] drží PrivateKey a Address, pak jeden [Peer] pro každý koncový bod s PublicKey, AllowedIPs a Endpoint. IKEv2 přichází jako .mobileconfig se slovníky užitečného zatížení místo bloků klíčů.
Žádný z těchto textů není sám o sobě pověřením. Pověřením je soukromý klíč a každý formát ho buď vloží dovnitř, nebo ukazuje na alias, který se vyřeší jen v klientovi, který ho vytvořil.
Kde klíč na Androidu skutečně žije
Android uchovává data aplikací pod /data/data/<package> a číst je může jen UID dané aplikace. Neexistuje podporovaný způsob, jak z telefonu bez rootu zkopírovat soukromý adresář jiné aplikace, a adb backup přestal být obecnou odpovědí poté, co ho Android 12 zrušil a klienti začali deklarovat allowBackup="false". Export z androidového klienta tedy znamená to, co daný klient implementuje, ne kopii souborového systému.
Vrstva identity leží pod aplikací. Pokud klient importoval váš klíč do Android Keystore, materiál se tam generuje nebo zabaluje a pozdější exporty mohou nést odkaz na alias v Keystore místo bajtů. Klíče s hardwarovou podporou jsou navrženy tak, že je nedokáže přečíst ani vlastnící aplikace, jak popisuje Keystore documentation, takže profil odkazující na tento alias se na stejném telefonu importuje čistě a všude jinde selže.
To není rozbitý export. To je vlastnost, kterou měla platforma poskytnout.
Co profil nedokáže přenést
Postavte objekty proti tomu, co cílové zařízení přijme:
| Objekt | Přenese se? | Proč |
|---|---|---|
| Protokol a koncový bod | Ano, pokud mu cílový klient rozumí | Prostý text v profilu |
| CA certifikát a kontrola názvu hostitele | Obvykle | Veřejný materiál, ale název hostitele musí stále odpovídat certifikátu |
| Klientský certifikát | Ano, pokud není vázán na zařízení | Certifikáty jsou přenosné; vydavatel rozhoduje, kolik zařízení smí jeden používat |
| Soukromý klíč | Jen pokud byl vygenerován mimo Keystore | Klíče s hardwarovou podporou nelze exportovat, pouze nahradit |
| Účet, MFA, relace SSO | Ne | Tokeny vyprší a zůstanou vázané na zařízení, které je získalo |
| Trasy, DNS a rozsah aplikací | Pouze jako konfigurační text | Android je aplikuje při připojení přes VpnService.Builder |
| Seznam aplikací pro rozdělený tunel | Vzácně | Názvy balíčků se mezi zařízeními liší a seznam je stav klienta |
Dva řádky způsobují většinu zmatku. Klíč vygenerovaný v zařízení a označený jako neexportovatelný skutečně zmizí s daty aplikace, takže náhradou je nový klíč a certifikát pro něj vydaný. Relační token zkopírovaný do nového telefonu obvykle zemře při prvním obnovení, což vypadá jako neúspěšný import.
Import je parsování a potom žádost o souhlas
Na přijímající straně je import parsování následované zápisem. Klient přečte konfiguraci, ověří, že každý odkazovaný blok existuje, a poté zapíše definici tunelu do svého sandboxu, a proto soubor, který jste vybrali ze Stažených souborů, není to, co se potom připojí.
Pak přichází autorizační krok, který žádný soubor nemůže přeskočit. Android vyžaduje, aby aplikace zavolala VpnService.prepare() a získala váš souhlas, než může vytvořit tunel, takže čerstvě importovaný profil ještě jednou zobrazí systémový dialog. Tunel se pak vytváří explicitně pomocí addAddress, addRoute, addDnsServer a addAllowedApplication nebo addDisallowedApplication pro směrování podle aplikací. Nic z toho nevyplývá z koncového bodu, takže stejný profil může ve dvou klientech vytvořit jinou sadu efektivních tras.
Nastavení založená na certifikátech přidávají ještě jedno rozvětvení. Když server vydá certifikát konkrétnímu zařízení, jak to dělá MDM a zápis SCEP, jeho opětovné použití na druhém telefonu buď funguje, dokud server nevynutí jednu relaci na identitu, nebo selže při TLS handshake. Před plánováním opětovného použití zkontrolujte zásady vydavatele.
Ověřte nové zařízení, než to staré vyřadíte
Nechte starý telefon připojený, dokud nový nepřejde něčím lepším než zelená ikona. Ověřte výstupní adresu z nového zařízení a DNS resolver, který skutečně použil. Pokud záleží na split tunneling, spusťte aplikaci, která má tunel obejít, a jednu, která nemá, a podívejte se, která dosáhne vašeho poskytovatele.
Jedna kontrola rozhodne o výstupní adrese. Otevřete https://ifconfig.me v prohlížeči telefonu, poté spusťte curl -s https://ifconfig.me z notebooku ve stejné Wi-Fi a obě odpovědi porovnejte s adresou, kterou vám přidělil poskytovatel.
Teprve pak vyřaďte starou identitu, a to prostřednictvím vydavatele: odvolejte certifikát nebo odeberte zařízení z účtu. Smazání souboru ze Stažených souborů nic neukončí, protože dvě zařízení se stejným certifikátem vypadají v protokolu serveru stejně.
Pokud se export ukáže jako nepřenosný, řešením je nová registrace, ne veřejný konfigurační balíček. Požádejte o profil pro druhé zařízení, nebo vygenerujte pár klíčů v novém telefonu a odešlete CSR; je to pomalejší a je to cesta, kterou vydavatel podporuje.
Projděte kontrolní seznam, než cokoli smažete: nové zařízení se připojí, výstupní adresa a DNS odpovídají, rozsah podle aplikací je takový, jak jste zamýšleli, stará identita je odvolána a každý konfigurační soubor, který jste si nechali, je v šifrovaném úložišti.