Android-VPN-Export: Was tatsächlich auf ein neues Smartphone übertragen wird
Ein Android-VPN-Export liefert Einstellungen und manchmal einen Schlüssel, aber nie die Geräteautorisierung. Prüfen Sie, was wirklich übergeht, bevor Sie das alte Smartphone löschen.
Einen VPN-Profil aus Android zu exportieren wirkt wie ein Backup-Schritt, und das Menü, das ihn anbietet, tut nichts, um diesen Eindruck zu korrigieren. Was Sie mitnehmen, ist eine Parser-Eingabe, ein Schlüssel, den das Betriebssystem möglicherweise nie zurückgibt, und eine Autorisierung, die genau für dieses Smartphone ausgestellt wurde. Trennen Sie diese drei Dinge, und die nützliche Frage taucht auf: Welcher Teil fehlt auf dem neuen Gerät noch?
Die Datei ist der leichte Teil. Die beiden anderen entscheiden, ob die Migration funktioniert.
Was ein exportiertes Profil tatsächlich enthält
Öffnen Sie die Datei in einem Texteditor, bevor Sie ihr vertrauen. Ein OpenVPN-Profil ist eine kleine Konfigurationssprache: remote, proto, data-ciphers und oft Inline-Blöcke <ca>, <cert>, <key> oder <tls-crypt>, die der Client an seinen TLS-Stack übergibt. Eine WireGuard-Konfiguration ist flacher: [Interface] enthält PrivateKey und Address, dann ein [Peer] pro Endpunkt mit PublicKey, AllowedIPs und Endpoint. IKEv2 kommt als .mobileconfig mit Payload-Wörterbüchern statt Schlüsselblöcken.
Nichts davon ist für sich genommen ein Berechtigungsnachweis. Der Berechtigungsnachweis ist der private Schlüssel, und jedes Format bettet ihn entweder inline ein oder verweist auf einen Alias, der nur innerhalb des Clients aufgelöst wird, der ihn erzeugt hat.
Wo der Schlüssel auf Android tatsächlich liegt
Android speichert App-Daten unter /data/data/<package>, lesbar allein für die UID dieser App. Es gibt keinen unterstützten Weg, ein privates Verzeichnis einer anderen App von einem nicht gerooteten Smartphone zu kopieren, und adb backup war keine allgemeine Antwort mehr, nachdem Android 12 es abgeschafft und Clients begonnen hatten, allowBackup="false" zu deklarieren. Ein Export aus einem Android-Client bedeutet also, was dieser Client implementiert, nicht eine Kopie des Dateisystems.
Die Identitätsschicht liegt unterhalb der App. Wenn ein Client Ihren Schlüssel in den Android Keystore importiert hat, wird das Material dort erzeugt oder eingepackt, und spätere Exporte können einen Verweis auf einen Keystore-Alias statt der Bytes tragen. Hardwaregestützte Schlüssel sind so gebaut, dass selbst die besitzende App sie nicht auslesen kann, wie Keystore documentation beschreibt, also importiert ein Profil, das auf diesen Alias verweist, auf demselben Smartphone sauber und scheitert überall sonst.
Das ist kein kaputter Export. Es ist die Eigenschaft, die von der Plattform verlangt wurde.
Was ein Profil nicht mitnehmen kann
Stellen Sie die Objekte dem gegenüber, was ein Ziel akzeptiert:
| Objekt | Überträgt? | Warum |
|---|---|---|
| Protokoll und Endpunkt | Ja, wenn der Zielclient es spricht | Klartext im Profil |
| CA-Zertifikat und Hostnamenprüfung | Meistens | Öffentliches Material, aber der Hostname muss weiterhin zum Zertifikat passen |
| Client-Zertifikat | Ja, sofern es nicht pro Gerät gebunden ist | Zertifikate sind portabel; der Aussteller entscheidet, wie viele Geräte eines nutzen dürfen |
| Privater Schlüssel | Nur wenn außerhalb des Keystore erzeugt | Hardwaregestützte Schlüssel lassen sich nicht exportieren, nur ersetzen |
| Konto, MFA, SSO-Sitzung | Nein | Tokens laufen ab und bleiben an das Gerät gebunden, das sie erhalten hat |
| Routen, DNS und App-Umfang | Nur als Konfigurationstext | Android wendet sie beim Verbinden über VpnService.Builder an |
| App-Liste für Split-Tunnel | Selten | Paketnamen unterscheiden sich zwischen Geräten, und die Liste ist Client-Zustand |
Zwei Zeilen verursachen den meisten Wirrwarr. Ein auf dem Gerät erzeugter und als nicht exportierbar markierter Schlüssel ist mit den App-Daten wirklich weg, die Ersetzung ist also ein neuer Schlüssel plus ein dafür ausgestelltes Zertifikat. Ein auf ein neues Smartphone kopiertes Sitzungstoken stirbt meist beim ersten Refresh, was wie ein fehlgeschlagener Import aussieht.
Import ist ein Parsen, dann eine Zustimmungsabfrage
Auf der Empfangsseite ist Import ein Parsen, gefolgt von einem Commit. Der Client liest die Konfiguration, prüft, dass jeder referenzierte Block existiert, und schreibt dann die Tunneldefinition in seine eigene Sandbox — deshalb ist die Datei, die Sie aus Downloads gewählt haben, nicht das, was sich danach verbindet.
Dann kommt ein Autorisierungsschritt, den keine Datei überspringen kann. Android verlangt, dass die App VpnService.prepare() aufruft und Ihre Zustimmung erhält, bevor sie einen Tunnel aufbauen darf, sodass ein frisch importiertes Profil den Systemdialog trotzdem einmal zeigt. Danach wird der Tunnel ausdrücklich über addAddress, addRoute, addDnsServer und addAllowedApplication oder addDisallowedApplication für app-basiertes Routing aufgebaut. Nichts davon ist durch einen Endpunkt impliziert, sodass dasselbe Profil in zwei Clients einen unterschiedlichen effektiven Routensatz erzeugen kann.
Zertifikatsbasierte Setups fügen eine weitere Gabelung hinzu. Wenn der Server einem bestimmten Gerät ein Zertifikat ausstellt, wie es MDM und SCEP-Enrollment tun, funktioniert die Wiederverwendung auf einem zweiten Smartphone entweder, bis der Server eine Sitzung pro Identität erzwingt, oder sie scheitert beim TLS-Handshake. Prüfen Sie die Richtlinie des Ausstellers, bevor Sie die Wiederverwendung planen.
Prüfen Sie das neue Gerät, bevor Sie das alte ausmustern
Halten Sie das alte Smartphone verbunden, bis das neue etwas Besseres als ein grünes Icon bestanden hat. Bestätigen Sie die Ausgangsadresse vom neuen Gerät und den DNS-Resolver, den es tatsächlich benutzt hat. Wenn split tunneling zählt, starten Sie eine App, die den Tunnel umgehen soll, und eine, die es nicht soll, und sehen Sie, welche Ihren Provider erreicht.
Eine Prüfung klärt die Ausgangsadresse. Öffnen Sie https://ifconfig.me im Browser des Smartphones, führen Sie dann curl -s https://ifconfig.me von einem Laptop im selben Wi-Fi aus und vergleichen Sie beide Antworten mit der Adresse, die Ihr Anbieter vergeben hat.
Erst dann mustern Sie die alte Identität aus, und zwar über den Aussteller: Widerrufen Sie das Zertifikat oder entfernen Sie das Gerät aus dem Konto. Eine Datei aus Downloads zu löschen beendet nichts, weil zwei Geräte mit demselben Zertifikat im Serverprotokoll identisch aussehen.
Erweist sich der Export als nicht portabel, ist die Lösung eine neue Registrierung statt eines öffentlichen Konfigurationsbündels. Fordern Sie ein zweites Geräteprofil an, oder erzeugen Sie das Schlüsselpaar auf dem neuen Smartphone und reichen Sie den CSR ein; langsamer, und es ist der Weg, den der Aussteller unterstützt.
Gehen Sie die Checkliste durch, bevor Sie etwas löschen: neues Gerät verbindet, Ausgangsadresse und DNS stimmen, App-Umfang ist wie beabsichtigt, alte Identität widerrufen, und jede aufbewahrte Konfigurationsdatei liegt in verschlüsseltem Speicher.