L2TP-automatisering op Android: een script kan erom vragen, niet het bouwen

De mythe is dat L2TP op Android nog iets is dat een shell-script kan starten: een route toevoegen, de oude service aanroepen, klaar. Dat kan niet, omdat vier verschillende lagen het eens moeten worden voordat een tunnel een pakket draagt. De IPsec-laag beschermt het pad, L2TP draagt de sessie, PPP onderhandelt de verbinding, en Android moet het resultaat registreren als een VPN waaromheen het kan routeren. Ik heb dit twee keer zien proberen met gekopieerde commando's, en beide keren bestond de route terwijl niets versleuteld was.

Wat een routewijziging werkelijk bereikt

Een route toevoegen bepaalt waar een pakket hierna heen gaat. Het onderhandelt geen beveiligingsassociatie, opent geen L2TP-sessie en voert de PPP-uitwisseling niet uit die een adres, een peer en DNS-instellingen oplevert. Op een telefoon is het zichtbare resultaat verkeer dat via het verkeerde pad vertrekt, of vertrekt en sterft, zonder tunnelstatus ergens.

Hetzelfde geldt voor een serviceaanroep die uit een oudere release is gekopieerd. De interne VPN-loodgieterij van Android is geen gepubliceerde automatiserings-API, en een genummerde transactie uit een andere versie kan een andere bewerking raken of privileges eisen die het script niet heeft. Een automatisering die een wachtwoord draagt, mag nooit afhangen van geraden interne argumenten, omdat de faalmodus ofwel een stille no-op is, ofwel een half gemaakt profiel dat niemand opruimt.

Vier eigenaren, en het script is er geen van

Neem ze in volgorde. IPsec zet het beschermde pad op en onderhoudt het, en authenticeert de peers. L2TP draagt de sessie eroverheen, en die gelaagdheid is de reden dat de standaard ze als afzonderlijke mechanismen behandelt en niet als één protocol. Binnenin onderhandelt PPP over de linkparameters die de client gebruikt. Daarna bezit Android de platformkant: de geregistreerde VPN-interface, bereik per app, always-on-status en de levenscyclus die bepaalt wat er gebeurt als de app wordt gedood.

Een script kan alleen de laatste van die lagen zien, en meestal indirect. Het kan een client vragen te verbinden als die client een gedocumenteerde besturing blootlegt, en het kan daarna de interfacestatus volgen. Het kan de drie lagen eronder niet vervangen, en het kan het platform niet zover krijgen dat het een niet-geregistreerde interface als VPN behandelt.

Waarom een daemon ook geen kortere weg is

Een bevoorrechte Linux-daemon op het apparaat starten lijkt het ontbrekende stuk, en vaak brengt die inderdaad een tunnel omhoog. Wat hij niet doet, is die tunnel bij Android registreren. De interface bestaat in de kernel, maar de VPN-selectie van het platform, routering per app, always-on-beleid en levenscyclus weten er niets van, en de eigen route- en DNS-wijzigingen van de daemon concurreren met de netwerkbeheerder om dezelfde tabellen.

Het resultaat is een verbinding die werkt voor het verkeer van de daemon en mysterieus niet voor de app die je belangrijk vond, of een die blijft bestaan tot het systeem zijn netwerken opnieuw beoordeelt. Geen van beide uitkomsten is een platformbug; het is de grens tussen een socket bezitten en de VPN-voorziening bezitten.

Hoe de ondersteunde paden eruitzien

Als de organisatie kan overstappen op een profiel dat Android zelf levert, is het platformpad het eerlijke. Vanaf API 30 ondersteunt VpnManager het inrichten en beheren van platform-VPN-profielen door apps, met een autorisatiestroom die aan de aanroepende app is gekoppeld. Het is geen L2TP-converter: het profielmodel dat het voor IKEv2 inricht, vertaalt een bestaande L2TP-configuratie niet, en van protocol wisselen is een migratie, geen hernoeming. Identiteiten, routes, privé-DNS en toegangsrechten moeten bewust worden overgedragen.

Als de dienst L2TP/IPsec moet blijven, is de ondersteunde combinatie een client en een OS-release die de operator daadwerkelijk documenteert, en het automatiseringscontract ervan als dat bestaat. Als er geen gedocumenteerde onbeheerde besturing is, is het juiste antwoord een ondersteunde handmatige verbinding, niet een kwetsbaar bevoorrecht script dat toevallig op één build werkt.

Wat een correcte automatisering doet

Met een gedocumenteerde besturing heeft de automatisering een kleine en verdedigbare taak: vraag de genoemde verbinding aan, wacht op gereedheid, stop bij een authenticatie- of installatiefout, voer de bedoelde werklast uit en laat het opruimen over aan het onderdeel dat de verbinding bezit. Inloggegevens blijven bij de client die weet hoe ze opgeslagen en geroteerd moeten worden.

Schrijf op welk onderdeel welke laag bezit voordat je de eerste regel schrijft, en controleer het resultaat daartegen:

• IPsec en PPP worden door de client afgehandeld, niet door de routes van het script.
• De verbinding verschijnt in de VPN-status van het platform, dus bereik per app en always-on gelden ervoor.
• Geen enkele interne serviceaanroep, transactienummer of geraden argument draagt een inloggegeven.
• Een fout bij welke stap dan ook laat geen half geregistreerd profiel achter.