Exportació de VPN a Android: què passa realment a un telèfon nou
Una exportació de VPN a Android envia la configuració i de vegades una clau, però mai l'autorització del dispositiu. Comproveu què es mou realment abans d'esborrar el telèfon antic.
Exportar un perfil de VPN des d'Android sembla un pas de còpia de seguretat, i el menú que ho ofereix no fa res per corregir aquesta impressió. El que us endueu és una entrada per a un analitzador, una clau que el sistema operatiu potser no retornarà mai i una autorització emesa per a aquell telèfon concret. Separeu aquestes tres coses i apareix la pregunta útil: quina peça encara falta al dispositiu nou?
El fitxer és la part fàcil. Les altres dues decideixen si la migració funciona.
Què conté realment un perfil exportat
Obriu el fitxer en un editor de text abans de confiar-hi. Un perfil OpenVPN és un petit llenguatge de configuració: remote, proto, data-ciphers i sovint blocs <ca>, <cert>, <key> o <tls-crypt> en línia que el client lliura a la seva pila TLS. Una configuració de WireGuard és més plana: [Interface] conté PrivateKey i Address, i després un [Peer] per punt final amb PublicKey, AllowedIPs i Endpoint. IKEv2 arriba com a .mobileconfig amb diccionaris de càrrega útil en lloc de blocs de claus.
Cap d'aquests textos no és una credencial per si mateix. La credencial és la clau privada, i cada format o la enganxa en línia o apunta a un àlies que només es resol dins del client que la va crear.
On viu realment la clau a Android
Android guarda les dades de les aplicacions a /data/data/<package>, llegibles només pel UID d'aquella aplicació. No hi ha cap manera compatible de copiar el directori privat d'una altra aplicació des d'un telèfon sense root, i adb backup va deixar de ser una resposta general quan Android 12 el va desaprovar i els clients van començar a declarar allowBackup="false". Per tant, una exportació des d'un client Android significa el que aquell client implementa, no una còpia del sistema de fitxers.
La capa d'identitat se situa sota l'aplicació. Si un client ha importat la vostra clau al Android Keystore, el material es genera o s'embolcalla allà, i les exportacions posteriors poden portar una referència a un àlies del Keystore en lloc dels bytes. Les claus amb suport de maquinari estan fetes de manera que ni l'aplicació propietària les pot llegir, tal com descriu Keystore documentation, així que un perfil que apunta a aquest àlies s'importa net al mateix telèfon i falla a qualsevol altre lloc.
Això no és una exportació trencada. És la propietat que es va demanar a la plataforma que oferís.
Què no pot traslladar un perfil
Compareu els objectes amb el que acceptarà una destinació:
| Objecte | Es trasllada? | Per què |
|---|---|---|
| Protocol i punt final | Sí, si el client de destinació el suporta | Text pla al perfil |
| Certificat de CA i comprovació del nom d'amfitrió | Normalment | Material públic, però el nom d'amfitrió encara ha de coincidir amb el certificat |
| Certificat de client | Sí, tret que estigui lligat per dispositiu | Els certificats són portables; l'emissor decideix quants dispositius poden fer servir un |
| Clau privada | Només si s'ha generat fora del Keystore | Les claus amb suport de maquinari no es poden exportar, només substituir |
| Compte, MFA, sessió SSO | No | Els testimonis caduquen i queden lligats al dispositiu que els ha obtingut |
| Rutes, DNS i abast de les aplicacions | Només com a text de configuració | Android les aplica en connectar mitjançant VpnService.Builder |
| Llista d'aplicacions de túnel dividit | Rarament | Els noms de paquet difereixen entre dispositius, i la llista és estat del client |
Dues files causen la major part de la confusió. Una clau generada al dispositiu i marcada com a no exportable desapareix realment amb les dades de l'aplicació, així que la substitució és una clau nova més un certificat emès per a ella. Un testimoni de sessió copiat a un telèfon nou normalment mor al primer refresc, cosa que es llegeix com una importació fallida.
La importació és una anàlisi i després una petició de consentiment
Al costat receptor, la importació és una anàlisi seguida d'una confirmació. El client llegeix la configuració, comprova que cada bloc referenciat existeix i després escriu la definició del túnel al seu propi entorn aïllat, i per això el fitxer que heu triat a Baixades no és el que es connecta després.
Després ve un pas d'autorització que cap fitxer pot saltar-se. Android exigeix que l'aplicació cridi VpnService.prepare() i rebi el vostre consentiment abans de poder establir un túnel, així que un perfil acabat d'importar encara mostra el diàleg del sistema una vegada. Llavors el túnel es construeix explícitament amb addAddress, addRoute, addDnsServer i addAllowedApplication o addDisallowedApplication per a l'encaminament per aplicació. Res d'això no ve implicat per un punt final, així que el mateix perfil pot produir un conjunt de rutes efectives diferent en dos clients.
Les configuracions basades en certificats afegeixen una bifurcació més. Quan el servidor emet un certificat a un dispositiu concret, com fan MDM i l'enrolament SCEP, reutilitzar-lo en un segon telèfon o bé funciona fins que el servidor imposa una sessió per identitat o bé falla a l'apretada de mans TLS. Comproveu la política de l'emissor abans de planejar reutilitzar-lo.
Verifiqueu el dispositiu nou abans de retirar el vell
Manteniu el telèfon antic connectat fins que el nou hagi superat alguna cosa millor que una icona verda. Confirmeu l'adreça de sortida des del dispositiu nou i el resolutor DNS que ha utilitzat realment. Si split tunneling importa, engegueu una aplicació que hauria d'evitar el túnel i una que no, i mireu quina arriba al vostre proveïdor.
Una comprovació resol l'adreça de sortida. Obriu https://ifconfig.me al navegador del telèfon, després executeu curl -s https://ifconfig.me des d'un portàtil a la mateixa Wi-Fi i compareu les dues respostes amb l'adreça que us ha assignat el proveïdor.
Només llavors retira la identitat antiga, i fes-ho a través de l'emissor: revoca el certificat o treu el dispositiu del compte. Esborrar un fitxer de Baixades no acaba res, perquè dos dispositius amb el mateix certificat es veuen idèntics al registre del servidor.
Si l'exportació resulta no portable, la solució és una inscripció nova i no un paquet de configuració públic. Demaneu un perfil per a un segon dispositiu, o genereu el parell de claus al telèfon nou i envieu la CSR; és més lent, i és el camí que l'emissor admet.
Executeu la llista de comprovació abans d'esborrar res: el dispositiu nou es connecta, l'adreça de sortida i el DNS coincideixen, l'abast per aplicació és el que volíeu, la identitat antiga està revocada i qualsevol fitxer de configuració que hàgiu guardat és en emmagatzematge xifrat.