L2TP-Automatiséierung op Android: e Skript kann ufroen, net bauen
E Shell-Route bréngt L2TP/IPsec op Android net erop. IPsec, L2TP, PPP a Plattformpolitik hunn jidderee säin Deel, dofir wielt, wat et kontrolléiere kann.
De Mythos ass, datt L2TP op Android nach eng Saach ass, déi e Shell-Skript starte kann: eng Route bäisetzen, den ale Service ruffen, fäerdeg. Dat kann net sinn, well véier verschidde Schichten sech eens musse ginn, ier en Tunnel e Paket dréit. D'IPsec-Schicht schützt de Wee, L2TP dréit d'Sessioun, PPP verhandelt d'Verbindung, an Android muss d'Resultat als VPN registréieren, ëm déi et routere kann. Ech hunn dat zweemol mat kopéierten Kommandoen gesinn, an zweemol war de Wee do, wärend näischt verschlësselt war.
Wat eng Routenännerung tatsächlech erreecht
Eng Route bäisetzen entscheet, wou e Paket als nächst hi geet. Et verhandelt keng Sécherheetsassociatioun, et mécht keng L2TP-Sessioun op, an et leeft net den PPP-Austausch, deen eng Adress, en Peer an DNS-Astellungen produzéiert. Op engem Handy ass d'siichtbar Resultat Traffic, deen iwwer de falsche Wee fortgeet, oder fortgeet an stierft, ouni Tunnelzoustand iergendwou.
Datselwecht gëllt fir en Service-Uriff, deen aus enger eelerer Verëffentlechung kopéiert gouf. Android seng intern VPN-Plomberie ass keng publizéiert Automatiséierungs-API, an eng numeréiert Transaktioun aus enger anerer Versioun kann eng aner Operatioun treffen oder Privilegien froen, déi d'Skript net huet. Eng Automatiséierung, déi e Passwuert dréit, sollt ni op geglaut intern Argumenter vertrauen, well de Fehlermodus entweder en duusscht No-op oder e hallef ugeluechten Profil ass, deen een net botzt.
Véier Besëtzer, an d'Skript ass keng vun hinnen
Hëlt se der Rei no. IPsec baut de geschützte Wee op an erhält en a authentifizéiert d'Peeren. L2TP dréit d'Sessioun driwwer, an d'Schichtung ass de Grond, firwat den Standard se als getrennt Mechanismen behandelt an net als een Protokoll. Bannen deem verhandelt PPP d'Verbindungsparameter, déi de Client benotzt. Duerno ass Android op der Plattformsäit: d'registréiert VPN-Schnittstell, de Beräich pro App, den Always-on-Zoustand an de Liewenszyklus, deen entscheet, wat geschitt, wann d'App ëmbruecht gëtt.
Eng Skript kann nëmmen déi lescht vun dëse Schichte gesinn, an dat meeschtens indirekt. Et kann e Client froen, sech ze verbannen, wann dee Client eng dokumentéiert Kontroll ubitt, an et kann duerno den Zoustand vun der Schnittstell observéieren. Et kann déi dräi Schichten drënner net ersetzen, an et kann d'Plattform net dozou bréngen, eng net registréiert Schnittstell als VPN ze behandelen.
Firwat och en Daemon kee Schrägwee ass
En privilegéierten Linux-Daemon um Apparat starten gesäit aus wéi de fehlenden Deel, an et bréngt dacks wierklech en Tunnel erop. Wat et net mécht, ass deen Tunnel bei Android ze registréieren. D'Schnittstell existéiert am Kernel, awer d'VPN-Auswiel vun der Plattform, d'Routing pro App, d'Always-on-Politik an de Liewenszyklus wëssen näischt dovun, an dem Daemon seng eegen Route- an DNS-Ännerungen konkurréiere mat dem Netzwierkmanager ëm déi selwecht Tabellen.
D'Resultat ass eng Verbindung, déi fir den Traffic vum Daemon funktionéiert an op mysteriéis Manéier net fir d'App, déi dir wichteg war, oder eng, déi iwwerlieft bis de System seng Netzwierker nei bewäert. Keng vun den zwou Ausgäng ass e Plattformbug; et ass d'Grenz tëscht engem Socket besëtzen an d'VPN-Anlag besëtzen.
Wéi déi ënnerstëtzt Weeër ausgesinn
Wann d'Organisatioun op e Profil ka wiesselen, deen Android selwer bitt, ass de Plattformswee den éierlechen. Vun API 30 un ënnerstëtzt VpnManager d'Bereetstellung a Kontroll vu Plattform-VPN-Profiler duerch Appen, mat engem Autorisatiounsfloss, deen un d'App gebonnen ass, déi oprufft. Et ass keen L2TP-Konverter: de Profilmodell, deen en fir IKEv2 bereetstellt, iwwersetzt keng existéierend L2TP-Konfiguratioun, an de Protokollwiessel ass eng Migratioun, net eng Ëmbenennung. Identitéiten, Routen, privaten DNS a Zougangsberechtegungen mussen absichtlech iwwerdroe ginn.
Wann de Service L2TP/IPsec misst bleiwen, ass déi ënnerstëtzt Kombinatioun e Client an eng OS-Verëffentlechung, déi den Bedreiwer wierklech dokumentéiert, an hire Automatiséierungsvertrag, wann et en gëtt. Wann et keng dokumentéiert onbewaacht Kontroll gëtt, ass déi richteg Äntwert eng ënnerstëtzt manuell Verbindung an net eng fragil privilegéiert Skript, déi zoufälleg op engem Build funktionéiert.
Wat eng korrekt Automatiséierung mécht
Mat enger dokumentéierter Kontroll huet d'Automatiséierung eng kleng a verdeedegbar Aufgab: déi genannte Verbindung ufroen, op Bereetschaft waarden, bei Authentifikatiouns- oder Setup-Fehler stoppen, déi virgesinn Aarbecht lafen an d'Botze dem Komponent iwwerloossen, deen d'Verbindung besëtzt. D'Berechtegungen bleiwen beim Client, deen weess, wéi een se späichert a rotéiert.
Schreift op, wéi ee Komponent wéi eng Schicht besëtzt, ier Dir déi éischt Linn schreift, a kontrolléiert d'Resultat dogéint:
- IPsec an PPP ginn vum Client gehandhabt, net vun de Route vun der Skript.
- D'Verbindung erschéngt am VPN-Zoustand vun der Plattform, dofir gëllen de Beräich pro App an Always-on fir si.
- Keen internen Service-Uriff, Transaktiounsnummer oder geglauten Argument dréit eng Berechtegung.
- E Fehler op engem Schrëtt hannerléisst keen hallef registréierte Profil.