Android VPN-export: mi kerül át valójában egy új telefonra
Az Android VPN-export beállításokat és néha kulcsot küld, de soha nem az eszköz engedélyezését. Ellenőrizze, mi megy át valójában, mielőtt törli a régi telefont.
A VPN-profil exportálása Androidról biztonsági mentés lépésének tűnik, és az ezt kínáló menü semmit sem tesz ennek a benyomásnak a korrigálására. Amivel távozik, az egy parser-bemenet, egy kulcs, amelyet az operációs rendszer talán soha nem ad vissza, és egy pontosan ehhez a telefonhoz kiadott engedélyezés. Válassza szét ezt a hármat, és megjelenik a hasznos kérdés: melyik rész hiányzik még az új eszközön?
A fájl a könnyű rész. A másik kettő dönti el, hogy a migráció működik-e.
Mit tartalmaz valójában egy exportált profil
Nyissa meg a fájlt egy szövegszerkesztőben, mielőtt megbízna benne. Az OpenVPN-profil egy kis konfigurációs nyelv: remote, proto, data-ciphers, és gyakran beágyazott <ca>, <cert>, <key> vagy <tls-crypt> blokkok, amelyeket a kliens a TLS-veremének ad. A WireGuard-konfiguráció laposabb: [Interface] tartalmazza a PrivateKey és Address elemeket, majd végpontonként egy [Peer] a PublicKey, AllowedIPs és Endpoint értékekkel. Az IKEv2 .mobileconfig formában érkezik hasznos teher szótárakkal kulcsblokkok helyett.
E szövegek egyike sem hitelesítő adat önmagában. A hitelesítő adat a privát kulcs, és minden formátum vagy beágyazza, vagy egy olyan álnévre mutat, amely csak az azt létrehozó kliensen belül oldódik fel.
Hol él valójában a kulcs az Androidon
Az Android az alkalmazásadatokat a /data/data/<package> alatt tárolja, amelyet csak az adott alkalmazás UID-je olvashat. Nincs támogatott mód arra, hogy egy rootolatlan telefonról másik alkalmazás privát könyvtárát másolja, és a adb backup megszűnt általános válasznak lenni, miután az Android 12 elavulttá tette, és a kliensek elkezdték deklarálni a allowBackup="false" értéket. Tehát az Android-kliensből történő export azt jelenti, amit az a kliens megvalósít, nem a fájlrendszer másolatát.
Az identitásréteg az alkalmazás alatt helyezkedik el. Ha egy kliens a kulcsát az Android Keystore-ba importálta, az anyag ott generálódik vagy csomagolódik, és a későbbi exportok a bájtok helyett egy Keystore-álnévre mutató hivatkozást hordozhatnak. A hardveresen támogatott kulcsok úgy épülnek fel, hogy még a tulajdonos alkalmazás sem tudja kiolvasni őket, ahogy a Keystore documentation leírja, így az arra az álnévre mutató profil ugyanazon a telefonon tisztán importálódik, mindenhol máshol pedig meghiúsul.
Ez nem törött export. Ez az a tulajdonság, amelyet a platformtól kértek.
Mit nem tud átvinni egy profil
Állítsa az objektumokat szembe azzal, amit a cél befogad:
| Objektum | Átkerül? | Miért |
|---|---|---|
| Protokoll és végpont | Igen, ha a célkliens ismeri | Sima szöveg a profilban |
| CA-tanúsítvány és hosztnév-ellenőrzés | Általában | Nyilvános anyag, de a hosztnévnek továbbra is egyeznie kell a tanúsítvánnyal |
| Kliens-tanúsítvány | Igen, kivéve ha eszközönként kötött | A tanúsítványok hordozhatók; a kibocsátó dönti el, hány eszköz használhat egyet |
| Privát kulcs | Csak ha a Keystore-on kívül generálták | A hardveresen támogatott kulcsok nem exportálhatók, csak lecserélhetők |
| Fiók, MFA, SSO-munkamenet | Nem | A tokenek lejárnak, és ahhoz az eszközhöz kötődnek, amely megszerezte őket |
| Útvonalak, DNS és alkalmazáshatókör | Csak konfigurációs szövegként | Az Android csatlakozáskor a VpnService.Builder segítségével alkalmazza őket |
| Osztott alagút alkalmazáslista | Ritkán | A csomagnevek eltérnek az eszközök között, és a lista kliensállapot |
Két sor okozza a legtöbb zavart. Az eszközön generált és nem exportálhatónak jelölt kulcs valóban eltűnik az alkalmazásadatokkal, ezért a helyettesítés egy új kulcs és egy hozzá kiadott tanúsítvány. Az új telefonra másolt munkamenet-token általában az első frissítéskor meghal, ami sikertelen importnak tűnik.
Az import egy elemzés, majd egy hozzájárulási kérés
A fogadó oldalon az import egy elemzés, amelyet commit követ. A kliens beolvassa a konfigurációt, ellenőrzi, hogy minden hivatkozott blokk létezik, majd beírja az alagút definícióját a saját homokozójába, ezért nem az a fájl csatlakozik utána, amelyet a Letöltésekből kiválasztott.
Aztán jön egy engedélyezési lépés, amelyet egyetlen fájl sem ugorhat át. Az Android megköveteli, hogy az alkalmazás meghívja a VpnService.prepare() parancsot, és megszerezze a hozzájárulását, mielőtt alagutat hozhat létre, így a frissen importált profil még egyszer megmutatja a rendszerpárbeszédet. Ezután az alagút kifejezetten a addAddress, addRoute, addDnsServer, valamint az alkalmazásonkénti útválasztáshoz a addAllowedApplication vagy addDisallowedApplication segítségével épül fel. Ezek egyikét sem implikálja egy végpont, ezért ugyanaz a profil két kliensben eltérő tényleges útvonalkészletet eredményezhet.
A tanúsítványalapú beállítások még egy elágazást adnak. Amikor a kiszolgáló egy adott eszköznek tanúsítványt ad ki, ahogy az MDM és az SCEP-regisztráció teszi, a második telefonon való újrafelhasználás vagy addig működik, amíg a kiszolgáló identitásonként egy munkamenetet nem kényszerít, vagy a TLS-kézfogásnál meghiúsul. Az újrafelhasználás tervezése előtt ellenőrizze a kibocsátó szabályzatát.
Ellenőrizze az új eszközt, mielőtt kivonná a régit
Tartsa csatlakoztatva a régi telefont, amíg az új át nem megy valami zöld ikonnál jobbon. Erősítse meg az új eszköz kimenő címét és a ténylegesen használt DNS-feloldót. Ha a split tunneling számít, indítson el egy alkalmazást, amelynek meg kell kerülnie az alagutat, és egyet, amelynek nem, majd nézze meg, melyik éri el a szolgáltatóját.
Egy ellenőrzés eldönti a kimenő címet. Nyissa meg a https://ifconfig.me oldalt a telefon böngészőjében, majd futtassa a curl -s https://ifconfig.me parancsot egy laptopról ugyanazon a Wi-Fi-n, és hasonlítsa össze mindkét választ a szolgáltatója által kiosztott címmel.
Csak ezután vonja ki a régi identitást, és a kibocsátón keresztül tegye: vonja vissza a tanúsítványt, vagy távolítsa el az eszközt a fiókból. Egy fájl törlése a Letöltésekből semmit sem fejez be, mert két azonos tanúsítványú eszköz ugyanúgy néz ki a kiszolgálónaplóban.
Ha az export nem hordozhatónak bizonyul, a megoldás új regisztráció, nem nyilvános konfigurációs csomag. Kérjen profilt egy második eszközhöz, vagy generálja a kulcspárt az új telefonon, és nyújtsa be a CSR-t; lassabb, és ez az az út, amelyet a kibocsátó támogat.
Fussa át az ellenőrzőlistát, mielőtt bármit törölne: az új eszköz csatlakozik, a kimenő cím és a DNS egyezik, az alkalmazásonkénti hatókör az, amit szánt, a régi identitás visszavonva, és minden megtartott konfigurációs fájl titkosított tárolóban van.