Eksportowanie profilu VPN z Androida wygląda jak krok tworzenia kopii zapasowej, a menu, które to oferuje, nie robi nic, by poprawić to wrażenie. Zostaje ci wejście dla parsera, klucz, którego system może nigdy nie zwrócić, oraz autoryzacja wydana właśnie temu telefonowi. Rozdziel te trzy rzeczy, a pojawi się użyteczne pytanie: której części wciąż brakuje na nowym urządzeniu?

Plik to łatwa część. Pozostałe dwie decydują, czy migracja się powiedzie.

Co naprawdę zawiera wyeksportowany profil

Otwórz plik w edytorze tekstu, zanim mu zaufasz. Profil OpenVPN to mały język konfiguracji: remote, proto, data-ciphers i często wbudowane bloki <ca>, <cert>, <key> lub <tls-crypt>, które klient przekazuje swojej stosie TLS. Konfiguracja WireGuard jest prostsza: [Interface] zawiera PrivateKey i Address, potem po jednym [Peer] na punkt końcowy z PublicKey, AllowedIPs i Endpoint. IKEv2 przychodzi jako .mobileconfig ze słownikami ładunku zamiast bloków kluczy.

Żaden z tych tekstów nie jest sam w sobie poświadczeniem. Poświadczeniem jest klucz prywatny, a każdy format albo wkleja go do środka, albo wskazuje alias, który rozwiązuje się tylko wewnątrz klienta, który go utworzył.

Gdzie klucz naprawdę mieszka na Androidzie

Android trzyma dane aplikacji w /data/data/<package>, czytelne tylko dla UID tej aplikacji. Nie ma wspieranego sposobu skopiowania prywatnego katalogu innej aplikacji z telefonu bez roota, a adb backup przestał być ogólną odpowiedzią, gdy Android 12 go wycofał, a klienci zaczęli deklarować allowBackup="false". Eksport z klienta Android oznacza więc to, co ten klient implementuje, a nie kopię systemu plików.

Warstwa tożsamości leży pod aplikacją. Jeśli klient zaimportował twój klucz do Android Keystore, materiał jest tam generowany lub opakowywany, a późniejsze eksporty mogą nieść odwołanie do aliasu Keystore zamiast bajtów. Klucze wspierane sprzętowo są zbudowane tak, że nawet aplikacja będąca właścicielem nie może ich odczytać, jak opisuje Keystore documentation, więc profil wskazujący ten alias importuje się czysto na tym samym telefonie i zawodzi wszędzie indziej.

To nie jest zepsuty eksport. To właściwość, o którą poproszono platformę.

Czego profil nie może przenieść

Zestaw obiekty z tym, co przyjmie cel:

ObiektPrzenosi się?Dlaczego
Protokół i punkt końcowyTak, jeśli klient docelowy to obsługujeZwykły tekst w profilu
Certyfikat CA i sprawdzanie nazwy hostaZwykleMateriał publiczny, ale nazwa hosta nadal musi pasować do certyfikatu
Certyfikat klientaTak, chyba że jest przypisany do urządzeniaCertyfikaty są przenośne; wystawca decyduje, ile urządzeń może używać jednego
Klucz prywatnyTylko jeśli wygenerowano go poza KeystoreKluczy wspieranych sprzętowo nie można wyeksportować, tylko zastąpić
Konto, MFA, sesja SSONieTokeny wygasają i pozostają przypisane do urządzenia, które je uzyskało
Trasy, DNS i zakres aplikacjiTylko jako tekst konfiguracjiAndroid stosuje je przy połączeniu przez VpnService.Builder
Lista aplikacji w tunelu dzielonymRzadkoNazwy pakietów różnią się między urządzeniami, a lista jest stanem klienta

Dwa wiersze powodują większość zamieszania. Klucz wygenerowany na urządzeniu i oznaczony jako nieeksportowalny naprawdę znika wraz z danymi aplikacji, więc zamianą jest nowy klucz plus certyfikat dla niego wydany. Token sesji skopiowany na nowy telefon zwykle ginie przy pierwszym odświeżeniu, co wygląda jak nieudany import.

Import to parsowanie, a potem prośba o zgodę

Po stronie odbierającej import to parsowanie, po którym następuje zapis. Klient czyta konfigurację, sprawdza, czy istnieje każdy wskazany blok, a następnie zapisuje definicję tunelu w swojej piaskownicy, dlatego plik wybrany z Pobranych nie jest tym, co się potem łączy.

Potem przychodzi krok autoryzacji, którego żaden plik nie może pominąć. Android wymaga, aby aplikacja wywołała VpnService.prepare() i uzyskała twoją zgodę, zanim ustanowi tunel, więc świeżo zaimportowany profil i tak raz pokazuje okno systemowe. Następnie tunel jest budowany jawnie przez addAddress, addRoute, addDnsServer oraz addAllowedApplication lub addDisallowedApplication dla routingu per aplikacja. Nic z tego nie wynika z punktu końcowego, więc ten sam profil może dać inny zestaw efektywnych tras w dwóch klientach.

Konfiguracje oparte na certyfikatach dodają jeszcze jedno rozgałęzienie. Gdy serwer wydaje certyfikat konkretnemu urządzeniu, jak robią to MDM i rejestracja SCEP, ponowne użycie na drugim telefonie albo działa, dopóki serwer nie wymusi jednej sesji na tożsamość, albo zawodzi przy uzgadnianiu TLS. Sprawdź politykę wystawcy, zanim zaplanujesz ponowne użycie.

Zweryfikuj nowe urządzenie, zanim wycofasz stare

Trzymaj stary telefon podłączony, dopóki nowy nie przejdzie czegoś lepszego niż zielona ikona. Potwierdź adres wyjściowy z nowego urządzenia i resolver DNS, którego naprawdę użyło. Jeśli split tunneling ma znaczenie, uruchom aplikację, która powinna omijać tunel, i taką, która nie powinna, a potem zobacz, która dociera do twojego dostawcy.

Jedno sprawdzenie rozstrzyga adres wyjściowy. Otwórz https://ifconfig.me w przeglądarce telefonu, następnie uruchom curl -s https://ifconfig.me z laptopa w tej samej sieci Wi-Fi i porównaj obie odpowiedzi z adresem przydzielonym przez dostawcę.

Dopiero wtedy wycofaj starą tożsamość, i zrób to przez wystawcę: unieważnij certyfikat albo usuń urządzenie z konta. Usunięcie pliku z Pobranych niczego nie kończy, ponieważ dwa urządzenia z tym samym certyfikatem wyglądają w logu serwera identycznie.

Jeśli eksport okaże się nieprzenośny, rozwiązaniem jest nowa rejestracja, a nie publiczny pakiet konfiguracji. Poproś o profil dla drugiego urządzenia albo wygeneruj parę kluczy na nowym telefonie i wyślij CSR; wolniej, i to jest ścieżka, którą wspiera wystawca.

Przejdź listę kontrolną, zanim cokolwiek usuniesz: nowe urządzenie się łączy, adres wyjściowy i DNS się zgadzają, zakres per aplikacja jest taki, jak zamierzałeś, stara tożsamość jest unieważniona, a każdy zachowany plik konfiguracji leży w zaszyfrowanym magazynie.

Powiązane artykuły