Android 12 und IKEv1-VPN: Auslieferungsversion, IKEv2 und Drittanbieter-Apps

Zwei Telefone zeigen beide Android 12 in den Einstellungen, und nur eines davon startet noch das alte IPsec-XAuth-Profil, das Ihr Gateway anbietet. Der Unterschied ist keine Einstellung, die der Nutzer erreichen kann: Die Sperre, die den nativen IKEv1-Pfad steuert, prüft die SDK-Ebene, mit der das Gerät ausgeliefert wurde, nicht nur die aktuell laufende Version. Dieses eine Detail entscheidet, ob ein Flottenvergleich sinnvoll ist, und es entscheidet auch, welchen der drei Migrationspfade Sie wirklich brauchen.

Zwei Android-12-Telefone sind nicht derselbe Testfall

Die AOSP-Änderung, die neue Geräte daran hinderte, alte IKEv1-Profile zu starten, vergleicht DEVICE_INITIAL_SDK_INT mit Android S, also API 31. Auf dem nativen Startpfad löst ein passendes Profil einen Fehler wegen nicht unterstützter Operation aus, bevor überhaupt eine nutzbare Verbindung besteht. Ein Telefon, das mit Android 11 ausgeliefert und später aktualisiert wurde, passiert diese Sperre weiterhin; ein Modell, das mit Android 12 startete, nicht.

Sie können die beiden Zahlen auf einem Gerät mit aktivierter Fehlersuche lesen:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

Der erste Wert ist die Auslieferungsebene, auf die die Sperre schaut, der zweite das, was das Telefon heute ausführt. Fehlt die Eigenschaft, stützen Sie sich auf die Supportdokumentation des Modells statt auf eine Vermutung aus dem Marketingnamen, und nehmen Sie nicht an, dass ein Hersteller-Build alle Kompatibilitätspfade der Basisversion bewahrt.

Eine weitere Unterscheidung spart eine Stunde verlorener Supportzeit: Ein gespeichertes Profil, das noch in den VPN-Einstellungen steht, beweist nichts darüber, ob die Plattform es startet. Das erneute Eingeben des PSK oder das Bearbeiten von Routen kann eine früher laufende Protokollprüfung nicht entfernen, und der Fehler sieht wie ein Anmeldedatenproblem aus, obwohl er keines ist.

Pfad eins: den nativen Stack dort behalten, wo er noch läuft

Der alte Stack ist der, der IPsec-XAuth-PSK-, IPsec-Hybrid-RSA- und L2TP/IPsec-PSK-Profile aus dem System-VPN-Bildschirm liest. Auf einem Gerät, das unter API 31 ausgeliefert wurde, bleibt er nach einem Upgrade ein gangbarer Weg, weshalb ein Pilot auf einem älteren Gerät gelingen kann, während ein neues Gerät dasselbe Profil nicht startet.

Der Vergleich, der zählt, ist pro Geräteklasse, nicht pro Android-Version: Listen Sie die Modelle in der Flotte auf, lesen Sie ihre Auslieferungs-API-Ebenen und teilen Sie sie in Geräte, die das Profil noch starten, und solche, die es nicht können. Alles andere erzeugt eine Supportrichtlinie, die sich in dem Moment widerspricht, in dem ein Nutzer ein neues Telefon kauft.

Pfad zwei: IKEv2-Profile der Plattform

Androids öffentliches Bereitstellungsmodell für IKEv2 ist ein anderes Objekt, kein umbenanntes IKEv1-Profil. Die Plattform-API für IKEv2-Profile kam mit API 30 und erwartet IKEv2 mit dem Authentifizierungsverfahren, das das Gateway anbietet, meist zertifikatsbasiert oder EAP. Es gibt kein drahtkompatibles Upgrade von IKEv1 XAuth oder Hybrid auf IKEv2: Das Gateway muss für das neue Protokoll konfiguriert werden, und das Profil muss die passende Identität tragen.

Das ist der Pfad mit der längsten Lebensdauer und zugleich der, der die eigentliche Arbeit zeigt. Identitätsprüfung, Nutzerauthentifizierung, DNS, Split-Tunnel-Routen und Ressourcenautorisierung müssen die Migration überstehen; nur den Handshake gelingen zu lassen, lässt Nutzer in einem Tunnel, der nichts erreicht.

Der Rollout läuft meist über MDM oder eine verwaltete Konfiguration, statt dass der Nutzer Felder eintippt. Existiert diese Infrastruktur noch nicht, muss der Migrationsplan sie enthalten, denn ein IKEv2-Profil auf jedem Gerät von Hand neu einzugeben ist kein Vorgang, den ein Helpdesk absorbieren kann.

Pfad drei: eine Client-App eines Drittanbieters

Manche VPN-Apps bringen ihre eigene Protokollimplementierung mit und hängen gar nicht vom nativen Stack ab. Das macht sie zu einer legitimen Übergangslösung für eine Flotte, die nicht schnell migrieren kann, aber die Kompatibilitätsfrage wandert zur App: ob sie genau den IKEv1-Modus implementiert, den Ihr Gateway spricht, mit der Authentifizierung und den Cipher-Suites, die das Gateway verlangt.

Nehmen Sie die Supportmatrix der App als Autorität, nicht die Store-Beschreibung, und testen Sie ein echtes Gerät gegen das echte Gateway, bevor Sie sie empfehlen. Ein Telefon zu rooten, um einen entfernten Plattformpfad wiederherzustellen, ist ebenfalls keine gepflegte Lösung; es verschiebt das Problem in eine nicht unterstützte Konfiguration, die das nächste Systemupdate still brechen kann.

Wählen Sie nach dem, was das Gateway bieten kann

Die Entscheidung verengt sich, sobald Sie zwei Dinge wissen: welche Geräte auf oder nach API 31 gestartet sind und ob das Gateway einen IKEv2-Dienst mit demselben Registrierungsmodell anbieten kann. Wenn ja, migrieren Sie und investieren Sie nicht weiter in das alte Profil. Wenn noch nicht, behalten Sie IKEv1 für die Geräte, die es noch starten, und geben Sie neuen Geräten einen Drittanbieter-Client als dokumentierte, zeitlich begrenzte Ausnahme statt als unausgesprochenen Workaround.

Zwei Punkte machen den Plan verteidigbar. Erstens: Halten Sie den Grund jeder Ausnahme zusammen mit Modell und Auslieferungsebene fest, damit ein Prüfer sieht, dass die Grenze eine Plattformsperre ist und keine unerklärte Vorliebe. Zweitens: Behandeln Sie die Migration als geplante Arbeit: IKEv1 ist im Standardpfad veraltet (RFC 9395), was bedeutet, dass die verbleibenden Geräte weiter schrumpfen und die Ausnahmen mit ihnen auslaufen sollten.