L2TP-automatisering på Android: skriptet kan be om det, men ikke bygge det

Det er en myte at L2TP på Android er nok en ting et shell-skript kan starte: legg inn en rute, kall den gamle tjenesten, og du er ferdig. Det går ikke, fordi fire forskjellige lag må være enige før en tunnel kan føre en pakke. IPsec-laget beskytter veien, L2TP fører sesjonen, PPP forhandler om forbindelsen, og Android må registrere resultatet som en VPN det kan rute gjennom. Jeg har sett forsøk på dette to ganger med kopierte kommandoer, og begge gangene fantes ruten mens ingenting var kryptert.

Hva en ruteendring egentlig oppnår

Å legge inn en rute bestemmer hvor pakken skal gå videre. Det forhandler ikke en sikkerhetsassosiasjon, åpner ikke en L2TP-sesjon og kjører ikke PPP-utvekslingen som gir en adresse, en motpart 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 som er kopiert fra en eldre utgave. Androids interne VPN-opplegg er ikke et publisert automatiserings-API, og en nummerert transaksjon fra en annen versjon kan treffe en annen operasjon eller kreve rettigheter skriptet ikke har. En automatisering som bærer et passord, bør aldri stole på gjettede interne argumenter, siden feilmodusen enten er en stille no-op eller en halvferdig profil ingen rydder opp.

Fire eiere, og skriptet er ikke en av dem

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

Et skript kan bare se det siste av disse lagene, og som regel indirekte. Det kan be en klient om å koble til hvis klienten tilbyr en dokumentert kontroll, og det kan følge med på 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 heller ikke en daemon 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 tunnelen hos Android. Grensesnittet finnes i kjernen, men plattformens VPN-valg, ruting per app, always-on-policy og livssyklus kjenner det ikke, og daemonens egne rute- og DNS-endringer konkurrerer med nettverksbehandleren om de samme tabellene.

Resultatet er en forbindelse som virker for daemonens trafikk og merkelig nok ikke for appen du var opptatt av, eller en som består til systemet vurderer nettverkene sine på nytt. Ingen av delene er en feil i plattformen; det er grensen mellom å eie en socket og å eie VPN-funksjonen.

Slik ser de støttede veiene ut

Hvis organisasjonen kan gå over til en profil Android selv leverer, er plattformveien den ærlige. Fra API 30 støtter VpnManager at apper klargjør og styrer VPN-profiler i plattformen, 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 et navnebytte. Identiteter, ruter, privat DNS og tilgangstillatelser må overføres bevisst.

Hvis tjenesten må forbli L2TP/IPsec, er den støttede kombinasjonen en klient og en OS-utgave operatøren faktisk dokumenterer, og automatiseringsavtalen dens 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 build.

Hva en riktig automatisering gjør

Med en dokumentert kontroll har automatiseringen en liten og forsvarlig oppgave: be om den navngitte tilkoblingen, vent til den er klar, stopp ved feil i autentisering eller oppsett, kjør den planlagte arbeidsmengden, og la oppryddingen være hos komponenten som eier tilkoblingen. Påloggingsinformasjonen blir hos klienten som vet hvordan den skal lagres og roteres.

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

• IPsec og PPP håndteres av klienten, ikke av rutene i skriptet.
• Tilkoblingen vises i plattformens VPN-status, så omfang per app og always-on gjelder for den.
• Ingen interne tjenestekall, transaksjonsnumre eller gjettede argumenter bærer påloggingsinformasjon.
• Feil på et hvilket som helst trinn etterlater ingen halvregistrert profil.