L2TP-automatisering på Android: eit skript kan be om det, ikkje byggje det

Myten er at L2TP på Android er ein ting til som eit shell-skript kan starte: legg til ei rute, kall den gamle tenesta, ferdig. Det kan ikkje vere slik, fordi fire ulike lag må bli samde før ein tunnel fraktar ein pakke. IPsec-laget vernar vegen, L2TP fraktar sesjonen, PPP forhandlar om lenkja, og Android må registrere resultatet som ein VPN det kan rute rundt. Eg har sett dette freista to gonger med kopierte kommandoar, og begge gongene fanst ruta medan ingenting var kryptert.

Kva ei ruteendring faktisk oppnår

Å leggje til ei rute avgjer kvar ein pakke går neste gong. Det forhandlar ikkje ein tryggingsassosiasjon, det opnar ikkje ein L2TP-sesjon, og det køyrer ikkje PPP-utvekslinga som lagar ein adresse, ein peer og DNS-innstillingar. På ein telefon er det synlege resultatet trafikk som går ut feil veg, eller går ut og døyr, utan tunnelstatus nokon stad.

Det same gjeld eit tenestekall kopiert frå ei eldre utgåve. Androids interne VPN-røyr er ikkje eit publisert automatiserings-API, og ein nummerert transaksjon frå ein annan versjon kan treffe ein annan operasjon eller krevje privilegium skriptet ikkje har. Ein automatisering som ber eit passord bør aldri avhenge av gjette interne argument, fordi feilmodusen er anten ein stille no-op eller ein halvlaga profil ingen ryddar opp.

Fire eigarar, og skriptet er ingen av dei

Ta dei i rekkjefølgje. IPsec etablerer og vedlikeheld den verna vegen og autentiserer peerane. L2TP fraktar sesjonen over han, og lagdelinga er grunnen til at standarden behandlar dei som skilde mekanismar og ikkje som éin protokoll. Inne i det forhandlar PPP lenkeparameterane klienten skal bruke. Deretter eig Android plattformsida: det registrerte VPN-grensesnittet, omfang per app, always-on-tilstand og livssyklusen som avgjer kva som skjer når appen blir drepen.

Eit skript kan berre sjå det siste av desse laga, og vanlegvis indirekte. Det kan be ein klient kople til om klienten eksponerer ein dokumentert kontroll, og det kan overvake tilstanden til grensesnittet etterpå. Det kan ikkje erstatte dei tre laga under, og det kan ikkje få plattformen til å handsame eit uregistrert grensesnitt som ein VPN.

Kvifor ein daemon heller ikkje er ein snøggveg

Å starte ein privilegert Linux-daemon på eininga ser ut som den manglande brikka, og ofte får han verkeleg opp ein tunnel. Det han ikkje gjer, er å registrere den tunnelen hos Android. Grensesnittet finst i kjernen, men VPN-valet til plattformen, ruting per app, always-on-politikk og livssyklus veit ikkje om det, og daemonen sine eigne rute- og DNS-endringar konkurrerer med nettverkshandsamaren om dei same tabellane.

Resultatet er ei tilkopling som verkar for trafikken til daemonen og mystisk ikkje for appen du brydde deg om, eller ei som overlever til systemet vurderer nettverka sine på nytt. Ingen av utfalla er ein plattformfeil; det er grensa mellom å eige ein socket og å eige VPN-fasiliteten.

Korleis dei støtta vegane ser ut

Viss organisasjonen kan flytte til ein profil Android sjølv tilbyr, er plattformvegen den ærlege. Frå API 30 støttar VpnManager klargjering og kontroll av VPN-profilane til plattformen frå apper, med ein autorisasjonsflyt knytt til appen som kallar. Det er ikkje ein L2TP-konverter: profilmodellen han klargjer for IKEv2 omset ikkje ein eksisterande L2TP-konfigurasjon, og å byte protokoll er ein migrasjon, ikkje ei omdøyving. Identitetar, ruter, privat DNS og tilgangsløyve må overførast med vilje.

Viss tenesta må halde fram som L2TP/IPsec, er den støtta kombinasjonen ein klient og ei OS-utgåve operatøren faktisk dokumenterer, og automatiseringskontrakten hennar om han finst. Når det ikkje finst ein dokumentert ubemanna kontroll, er det rette svaret ei støtta manuell tilkopling, ikkje eit skjørt privilegert skript som tilfeldigvis verkar på éin bygg.

Kva ein korrekt automatisering gjer

Gitt ein dokumentert kontroll har automatiseringa ein liten og forsvarleg jobb: be om den namngjevne tilkoplinga, vent på klarsignal, stopp ved autentiserings- eller oppsettfeil, køyr den tiltenkte arbeidsmengda, og overlat oppryddinga til komponenten som eig tilkoplinga. Legitimasjonen blir hos klienten som veit korleis han skal lagrast og roterast.

Skriv ned kva komponent som eig kvart lag før du skriv den første linja, og sjekk resultatet mot det:

• IPsec og PPP blir handsama av klienten, ikkje av rutene til skriptet.
• Tilkoplinga viser seg i VPN-tilstanden til plattformen, så omfang per app og always-on gjeld for henne.
• Ingen interne tenestekall, transaksjonsnummer eller gjette argument ber legitimasjon.
• Feil på eitkvart steg etterlèt ingen halvregistrert profil.