L2TP-automatisering på Android: ett skript kan begära, inte bygga

Myten är att L2TP på Android är en sak till som ett shell-skript kan starta: lägg till en rutt, anropa den gamla tjänsten, klart. Det kan inte vara så, eftersom fyra olika lager måste komma överens innan en tunnel bär ett paket. IPsec-lagret skyddar vägen, L2TP bär sessionen, PPP förhandlar länken och Android måste registrera resultatet som en VPN som det kan routa runt. Jag har sett detta försökas två gånger med kopierade kommandon, och båda gångerna fanns rutten medan ingenting var krypterat.

Vad en ruttändring faktiskt åstadkommer

Att lägga till en rutt avgör vart ett paket tar vägen härnäst. Det förhandlar inte en säkerhetsassociation, öppnar ingen L2TP-session och kör inte PPP-utbytet som ger en adress, en peer och DNS-inställningar. På en telefon är det synliga resultatet trafik som går ut fel väg, eller går ut och dör, utan tunnelstatus någonstans.

Samma sak gäller ett tjänsteanrop som kopierats från en äldre version. Androids interna VPN-rördrag är inte ett publicerat automatiserings-API, och en numrerad transaktion från en annan version kan träffa en annan operation eller kräva privilegier som skriptet inte har. En automatisering som bär ett lösenord bör aldrig förlita sig på gissade interna argument, eftersom felmoden antingen är en tyst no-op eller en halvfärdig profil som ingen städar.

Fyra ägare, och skriptet är ingen av dem

Ta dem i ordning. IPsec upprättar och underhåller den skyddade vägen och autentiserar parterna. L2TP bär sessionen över den, och skiktningen är anledningen till att standarden behandlar dem som separata mekanismer och inte som ett protokoll. Inuti detta förhandlar PPP länkparametrarna som klienten ska använda. Sedan äger Android plattformssidan: det registrerade VPN-gränssnittet, omfattning per app, always-on-läget och livscykeln som avgör vad som händer när appen dödas.

Ett skript kan bara se det sista av dessa lager, och oftast indirekt. Det kan be en klient att ansluta om klienten exponerar en dokumenterad kontroll, och det kan följa gränssnittets status efteråt. Det kan inte ersätta de tre lagren under, och det kan inte få plattformen att behandla ett oregistrerat gränssnitt som en VPN.

Varför en daemon inte heller är en genväg

Att starta en privilegierad Linux-daemon på enheten ser ut som den saknade biten, och ofta får den verkligen upp en tunnel. Det den inte gör är att registrera tunneln hos Android. Gränssnittet finns i kärnan, men plattformens VPN-val, routning per app, always-on-policy och livscykel känner inte till det, och daemonens egna rutt- och DNS-ändringar konkurrerar med nätverkshanteraren om samma tabeller.

Resultatet är en anslutning som fungerar för daemonens trafik och mystiskt inte för appen du brydde dig om, eller en som överlever tills systemet omvärderar sina nätverk. Ingen av utgångarna är en plattformsbugg; det är gränsen mellan att äga en socket och att äga VPN-funktionen.

Hur de stödda vägarna ser ut

Om organisationen kan flytta till en profil som Android själv tillhandahåller är plattformsvägen den ärliga. Från API 30 stöder VpnManager att appar tillhandahåller och styr plattformens VPN-profiler, med ett auktoriseringsflöde knutet till appen som anropar. Det är ingen L2TP-omvandlare: profilmodellen den tillhandahåller för IKEv2 översätter inte en befintlig L2TP-konfiguration, och att byta protokoll är en migrering, inte en namnändring. Identiteter, rutter, privat DNS och åtkomsträttigheter måste föras över med avsikt.

Om tjänsten måste förbli L2TP/IPsec är den stödda kombinationen en klient och en OS-version som operatören faktiskt dokumenterar, och dess automatiseringskontrakt om ett sådant finns. När det inte finns någon dokumenterad obemannad kontroll är rätt svar en stödd manuell anslutning, inte ett skört privilegierat skript som råkar fungera på en enda build.

Vad en korrekt automatisering gör

Med en dokumenterad kontroll har automatiseringen en liten och försvarbar uppgift: begär den namngivna anslutningen, vänta på klartecken, stoppa vid autentiserings- eller installationsfel, kör den avsedda arbetsbelastningen och lämna städningen till komponenten som äger anslutningen. Uppgifterna stannar hos klienten som vet hur de ska lagras och roteras.

Skriv ned vilken komponent som äger varje lager innan du skriver den första raden, och kontrollera resultatet mot det:

• IPsec och PPP hanteras av klienten, inte av skriptets rutter.
• Anslutningen visas i plattformens VPN-status, så omfattning per app och always-on gäller för den.
• Inga interna tjänsteanrop, transaktionsnummer eller gissade argument bär uppgifter.
• Ett fel i vilket steg som helst lämnar ingen halvregistrerad profil.