Android L2TP-automatisering: Et script kan anmode, ikke bygge

Myten er, at L2TP på Android er endnu en ting, et script kan starte: tilføj en rute, kald den gamle tjeneste, færdig. Det kan ikke lade sig gøre, fordi fire forskellige lag skal enes, før en tunnel bærer en pakke. IPsec beskytter vejen, L2TP bærer sessionen, PPP forhandler forbindelsen, og Android skal registrere resultatet som et VPN, det kan rutte rundt om. Jeg har set det forsøgt to gange med kopierede kommandoer, og begge gange fandtes ruten, mens intet var krypteret.

Hvad en ruteændring faktisk opnår

At tilføje en rute afgør, hvor en pakke går hen næste gang. Det forhandler ikke en sikkerhedsassociation, åbner ikke en L2TP-session og kører ikke PPP-udvekslingen, der giver en adresse, en peer og DNS-indstillinger. På en telefon er det synlige resultat trafik, der forlader ad den forkerte vej, eller forlader og dør, uden nogen tunnelstilstand.

Det samme gælder et tjenestekald kopieret fra en ældre udgivelse. Androids interne VPN-rør er ikke et offentliggjort automatiserings-API, og en nummereret transaktion fra en anden version kan ramme en anden handling eller kræve privilegier, scriptet ikke har. Automatisering, der bærer en adgangskode, bør aldrig afhænge af gættede interne argumenter, fordi fejlen enten er en tavs null-operation eller en halvt oprettet profil, ingen rydder op i.

Fire ejere, og scriptet er ingen af dem

Tag dem i rækkefølge. IPsec opretter og vedligeholder den beskyttede vej og autentificerer parterne. L2TP bærer sessionen over den, og den lagdeling er grunden til, at standarden behandler dem som adskilte mekanismer og ikke som én protokol. Indeni forhandler PPP de forbindelsesparametre, klienten vil bruge. Derefter ejer Android platformsiden: det registrerede VPN-interface, app-omfanget, always-on-tilstanden og livscyklussen, der afgør, hvad der sker, når appen dræbes.

Et script kan kun se det sidste af disse lag, og som regel indirekte. Det kan bede en klient om at forbinde, hvis klienten tilbyder en dokumenteret styring, og bagefter overvåge interface-tilstanden. Det kan ikke erstatte de tre lag under og kan ikke få platformen til at behandle et uregistreret interface som et VPN.

Hvorfor en daemon heller ikke er en genvej

At starte en privilegeret Linux-daemon på enheden ligner den manglende brik, og den bringer ofte en tunnel op. Det, den ikke gør, er at registrere tunnelen hos Android. Interfacet findes i kernen, men platformens VPN-valg, routing pr. app, always-on-politik og livscyklus ved intet om det, og daemonens egne rute- og DNS-ændringer konkurrerer med netværkslederen om de samme tabeller.

Resultatet er en forbindelse, der virker for daemonens trafik og mystisk ikke for den app, du bekymrede dig om, eller en, der overlever, indtil systemet vurderer sine netværk igen. Ingen af udfaldene er en platformfejl; det er grænsen mellem at eje en socket og eje VPN-faciliteten.

Hvordan de understøttede veje ser ud

Hvis organisationen kan flytte til en profil, som Android selv leverer, er platformens vej den ærlige. Fra API 30, VpnManager understøtter levering og styring af platformens VPN-profiler fra applikationer, med et autorisationsforløb knyttet til den kaldende app. Det er ikke en L2TP-konverter: den profilmodel, den leverer til IKEv2, oversætter ikke en eksisterende L2TP-konfiguration, og protokolskift er en migrering, ikke en omdøbning. Identiteter, ruter, privat DNS og adgangstilladelser skal overføres bevidst.

Skal tjenesten blive på L2TP/IPsec, er den understøttede kombination en klient og en OS-udgivelse, som operatøren faktisk dokumenterer, og dens automatiseringskontrakt, hvis den findes. Når der ikke er dokumenteret ubemandet styring, er det rigtige svar en understøttet manuel forbindelse og ikke et skrøbeligt privilegeret script, der tilfældigvis virker på ét build.

Hvad en korrekt automatisering gør

Givet en dokumenteret styring har automatiseringen en lille og forsvarlig opgave: anmod om den navngivne forbindelse, vent på parathed, stop ved fejl i godkendelse eller opsætning, udfør det tilsigtede arbejde og overlad oprydningen til den komponent, der ejer forbindelsen. Legitimationsoplysninger bliver hos klienten, der ved, hvordan de lagres og roteres.

Skriv ned, hvilken komponent der ejer hvert lag, før du skriver den første linje, og kontroller resultatet mod det:

• IPsec og PPP håndteres af klienten, ikke af scriptets ruter.
• Forbindelsen vises i platformens VPN-tilstand, så app-omfang og always-on gælder for den.
• Intet internt tjenestekald, transaktionsnummer eller gættet argument bærer legitimationsoplysninger.
• Fejl på et hvilket som helst trin efterlader ikke en halvt registreret profil.