L2TP-automatisering på Android: et skript kan be om det, ikke bygge det

Myten er at L2TP på Android er én ting til som et shell-skript kan starte: legg til en rute, kall den gamle tjenesten, ferdig. Det kan ikke være slik, fordi fire ulike lag må bli enige før en tunnel frakter en pakke. IPsec-laget beskytter veien, L2TP frakter sesjonen, PPP forhandler om lenken, og Android må registrere resultatet som en VPN det kan rute rundt. Jeg har sett dette forsøkt to ganger med kopierte kommandoer, og begge gangene fantes ruten mens ingenting var kryptert.

Hva en ruteendring faktisk oppnår

Å legge til en rute avgjør hvor en pakke går neste gang. Det forhandler ikke en sikkerhetsassosiasjon, det åpner ikke en L2TP-sesjon, og det kjører ikke PPP-utvekslingen som produserer en adresse, en peer og DNS-innstillinger. På en telefon er det synlige resultatet trafikk som går ut feil vei, eller går ut og dør, uten tunnelstatus noe sted.

Det samme gjelder et tjenestekall kopiert fra en eldre utgivelse. Androids interne VPN-rør er ikke et publisert automatiserings-API, og en nummerert transaksjon fra en annen versjon kan treffe en annen operasjon eller kreve privilegier skriptet ikke har. En automatisering som bærer et passord bør aldri avhenge av gjettede interne argumenter, fordi feilmodusen er enten en stille no-op eller en halvlaget profil ingen rydder opp.

Fire eiere, og skriptet er ingen av dem

Ta dem i rekkefølge. IPsec etablerer og vedlikeholder den beskyttede veien og autentiserer peerne. L2TP frakter sesjonen over den, og lagdelingen er grunnen til at standarden behandler dem som separate mekanismer og ikke som én protokoll. Inne i det forhandler PPP lenkeparameterne klienten skal bruke. Deretter eier Android plattformsiden: det registrerte VPN-grensesnittet, omfang per app, always-on-tilstand og livssyklusen som avgjør hva som skjer når appen drepes.

Et skript kan bare se det siste av disse lagene, og vanligvis indirekte. Det kan be en klient koble til hvis klienten eksponerer en dokumentert kontroll, og det kan overvåke grensesnittets tilstand etterpå. Det kan ikke erstatte de tre lagene under, og det kan ikke få plattformen til å behandle et uregistrert grensesnitt som en VPN.

Hvorfor en daemon heller ikke er en snarvei

Å starte en privilegert Linux-daemon på enheten ser ut som den manglende brikken, og ofte får den virkelig opp en tunnel. Det den ikke gjør, er å registrere den tunnelen hos Android. Grensesnittet finnes i kjernen, men plattformens VPN-valg, ruting per app, always-on-policy og livssyklus vet ikke om det, og daemonens egne rute- og DNS-endringer konkurrerer med nettverksbehandleren om de samme tabellene.

Resultatet er en tilkobling som virker for daemonens trafikk og mystisk ikke for appen du brydde deg om, eller en som overlever til systemet vurderer nettverkene sine på nytt. Ingen av utfallene er en plattformfeil; det er grensen mellom å eie en socket og å eie VPN-fasiliteten.

Hvordan de støttede veiene ser ut

Hvis organisasjonen kan flytte til en profil Android selv tilbyr, er plattformveien den ærlige. Fra API 30 støtter VpnManager klargjøring og kontroll av plattformens VPN-profiler fra apper, med en autorisasjonsflyt knyttet til appen som kaller. Det er ikke en L2TP-konverter: profilmodellen den klargjør for IKEv2 oversetter ikke en eksisterende L2TP-konfigurasjon, og å bytte protokoll er en migrering, ikke en omdøping. Identiteter, ruter, privat DNS og tilgangstillatelser må overføres med vilje.

Hvis tjenesten må forbli L2TP/IPsec, er den støttede kombinasjonen en klient og en OS-utgivelse operatøren faktisk dokumenterer, og dens automatiseringskontrakt hvis den finnes. Når det ikke finnes en dokumentert ubemannet kontroll, er det riktige svaret en støttet manuell tilkobling, ikke et skjørt privilegert skript som tilfeldigvis virker på én bygg.

Hva en korrekt automatisering gjør

Gitt en dokumentert kontroll har automatiseringen en liten og forsvarlig jobb: be om den navngitte tilkoblingen, vent på klarsignal, stopp ved autentiserings- eller oppsettfeil, kjør den tiltenkte arbeidsbelastningen, og overlat oppryddingen til komponenten som eier tilkoblingen. Legitimasjonen blir hos klienten som vet hvordan den skal lagres og roteres.

Skriv ned hvilken komponent som eier hvert lag før du skriver den første linjen, og sjekk resultatet mot det:

• IPsec og PPP håndteres av klienten, ikke av skriptets ruter.
• Tilkoblingen vises i plattformens VPN-tilstand, så omfang per app og always-on gjelder for den.
• Ingen interne tjenestekall, transaksjonsnummer eller gjettede argumenter bærer legitimasjon.
• Feil på ethvert trinn etterlater ingen halvregistrert profil.