Android-L2TP-Automatisierung: Ein Skript kann anfordern, aber nicht aufbauen

Der Mythos ist, dass L2TP unter Android noch etwas ist, das ein Shell-Skript starten kann: Route hinzufügen, den alten Dienst aufrufen, fertig. Das kann nicht sein, denn vier verschiedene Schichten müssen übereinstimmen, bevor ein Tunnel ein Paket trägt. IPsec schützt den Pfad, L2TP trägt die Sitzung, PPP handelt die Verbindung aus, und Android muss das Ergebnis als VPN registrieren, um das herum es routen kann. Ich habe das zweimal mit kopierten Befehlen gesehen, und beide Male existierte die Route, während nichts verschlüsselt war.

Was eine Routenänderung tatsächlich bewirkt

Eine Route hinzuzufügen entscheidet, wohin ein Paket als Nächstes geht. Sie handelt keine Sicherheitsassoziation aus, öffnet keine L2TP-Sitzung und führt nicht den PPP-Austausch aus, der Adresse, Peer und DNS-Einstellungen liefert. Auf einem Gerät ist das sichtbare Ergebnis Verkehr, der über den falschen Pfad verlässt oder verlässt und stirbt, ohne jeden Tunnelzustand.

Dasselbe gilt für einen Dienstaufruf, der aus einer älteren Version kopiert wurde. Androids interne VPN-Infrastruktur ist keine veröffentlichte Automatisierungs-API, und eine nummerierte Transaktion aus einer anderen Version kann einen anderen Vorgang treffen oder Rechte verlangen, die das Skript nicht hat. Eine Automatisierung, die ein Passwort trägt, darf sich nie auf geratene interne Argumente stützen, denn der Fehlerfall ist entweder ein stilles Nichts oder ein halb erzeugtes Profil, das niemand aufräumt.

Vier Eigentümer, und das Skript ist keiner davon

Nehmen Sie sie der Reihe nach. IPsec baut den geschützten Pfad auf, hält ihn und authentifiziert die Peers. L2TP trägt die Sitzung darüber, und diese Schichtung ist der Grund, warum der Standard sie als getrennte Mechanismen und nicht als ein Protokoll behandelt. Darin handelt PPP die Verbindungsparameter aus, die der Client nutzen wird. Dann besitzt Android die Plattformseite: die registrierte VPN-Schnittstelle, den App-Bereich, den Always-on-Zustand und den Lebenszyklus, der entscheidet, was beim Beenden der App passiert.

Ein Skript sieht nur die letzte dieser Schichten, und meist indirekt. Es kann einen Client um Verbindung bitten, wenn dieser eine dokumentierte Steuerung anbietet, und danach den Schnittstellenzustand beobachten. Es kann die drei Schichten darunter nicht ersetzen und die Plattform nicht dazu bringen, eine nicht registrierte Schnittstelle als VPN zu behandeln.

Warum auch ein Daemon keine Abkürzung ist

Einen privilegierten Linux-Daemon auf dem Gerät zu starten sieht nach dem fehlenden Teil aus, und oft bringt er tatsächlich einen Tunnel hoch. Was er nicht tut, ist diesen Tunnel bei Android zu registrieren. Die Schnittstelle existiert im Kernel, aber die VPN-Auswahl der Plattform, das Routing pro App, die Always-on-Richtlinie und der Lebenszyklus wissen nichts davon, und die eigenen Routen- und DNS-Änderungen des Daemons konkurrieren mit dem Netzwerkmanager um dieselben Tabellen.

Das Ergebnis ist eine Verbindung, die für den Verkehr des Daemons funktioniert und für die App, die Ihnen wichtig war, rätselhafterweise nicht, oder eine, die überlebt, bis das System seine Netze neu bewertet. Keines der Ergebnisse ist ein Plattformfehler; es ist die Grenze zwischen dem Besitz eines Sockets und dem Besitz der VPN-Einrichtung.

Wie die unterstützten Wege aussehen

Wenn die Organisation zu einem Profil wechseln kann, das Android selbst bereitstellt, ist der Plattformweg der ehrliche. Ab API 30, VpnManager unterstützt die Bereitstellung und Steuerung von Plattform-VPN-Profilen durch Anwendungen, mit einem Autorisierungsablauf, der an die aufrufende App gebunden ist. Es ist kein L2TP-Konverter: das Profilmodell, das es für IKEv2 bereitstellt, übersetzt keine bestehende L2TP-Konfiguration, und ein Protokollwechsel ist eine Migration, keine Umbenennung. Identitäten, Routen, privates DNS und Zugriffsrechte müssen bewusst übertragen werden.

Muss der Dienst bei L2TP/IPsec bleiben, ist die unterstützte Kombination ein Client und eine OS-Version, die der Betreiber tatsächlich dokumentiert, und dessen Automatisierungsvertrag, falls es einen gibt. Ohne dokumentierte unbeaufsichtigte Steuerung ist die richtige Antwort eine unterstützte manuelle Verbindung und kein fragiles privilegiertes Skript, das zufällig auf einem Build funktioniert.

Was eine korrekte Automatisierung tut

Mit einer dokumentierten Steuerung hat die Automatisierung eine kleine und vertretbare Aufgabe: die benannte Verbindung anfordern, auf Bereitschaft warten, bei Authentifizierungs- oder Einrichtungsfehlern stoppen, die vorgesehene Arbeit ausführen und das Aufräumen der Komponente überlassen, die die Verbindung besitzt. Anmeldedaten bleiben bei dem Client, der sie zu speichern und zu wechseln weiß.

Schreiben Sie auf, welche Komponente welche Schicht besitzt, bevor Sie die erste Zeile schreiben, und prüfen Sie das Ergebnis daran:

• IPsec und PPP werden vom Client behandelt, nicht von den Routen des Skripts.
• Die Verbindung erscheint im VPN-Zustand der Plattform, sodass App-Bereich und Always-on dafür gelten.
• Kein interner Dienstaufruf, keine Transaktionsnummer und kein geratenes Argument trägt Anmeldedaten.
• Ein Fehler an irgendeinem Schritt hinterlässt kein halb registriertes Profil.