Android L2TP-outomatisering: @APOS@n skrip kan vra, nie bou nie

Die mite is dat L2TP op Android nog iets is wat ’n skrip kan begin: voeg ’n roete by, roep die ou diens, klaar. Dit kan nie, want vier verskillende lae moet saamstem voordat ’n tonnel ’n pakket dra. IPsec beskerm die pad, L2TP dra die sessie, PPP onderhandel die skakel, en Android moet die uitslag as ’n VPN registreer waarom dit kan roeteer. Ek het dit twee keer met gekopieerde opdragte sien probeer, en albei kere het die roete bestaan terwyl niks versleutel was nie.

Wat ’n roeteverandering werklik vermag

Om ’n roete by te voeg, besluit waar ’n pakket volgende heen gaan. Dit onderhandel nie ’n sekuriteitsassosiasie nie, dit open nie ’n L2TP-sessie nie, en dit voer nie die PPP-uitruiling uit wat ’n adres, ’n eweknie en DNS-instelling lewer nie. Op ’n selfoon sien jy net verkeer wat op die verkeerde pad vertrek, of vertrek en verdwyn, sonder enige tonneltoestand.

Dieselfde geld vir ’n diensoproep uit ’n ouer weergawe. Android se interne VPN-loodgieterswerk is nie ’n gepubliseerde outomatiserings-API nie, en ’n genommerde transaksie uit ’n ander weergawe kan ’n ander bewerking tref of voorregte vereis wat die skrip nie het nie. ’n Outomatisering wat ’n wagwoord dra, moet nooit op geraaide interne argumente staatmaak nie, want die fout is óf ’n stil no-op óf ’n halfgeskepte profiel wat niemand opruim nie.

Vier eienaars, en die skrip is nie een van hulle nie

Neem hulle in volgorde. IPsec vestig en onderhou die beskermde pad en verifieer die eweknieë. L2TP dra die sessie daaroor, en die laagindeling is waarom die standaard hulle as aparte meganismes eerder as een protokol behandel. Daarbinne onderhandel PPP die skakelparameters wat die kliënt sal gebruik. Android besit dan die platformkant: die geregistreerde VPN-koppelvlak, per-app-omvang, altyd-aan-toestand en die lewensiklus wat besluit wat gebeur wanneer die app vermoor word.

’n Skrip kan net die laaste van daardie lae sien, en gewoonlik indirek. Dit kan ’n kliënt vra om te koppel as daardie kliënt ’n gedokumenteerde beheer bied, en daarna die koppelvlaktoestand dophou. Dit kan nie die drie lae daaronder vervang nie, en dit kan nie die platform laat om ’n ongeregistreerde koppelvlak as ’n VPN te hanteer nie.

Waarom ’n daemon ook nie ’n kortpad is nie

Om ’n bevoorregte Linux-daemon op die toestel te begin, lyk na die ontbrekende stuk, en dit bring dikwels ’n tonnel op. Wat dit nie doen nie, is om daardie tonnel by Android te registreer. Die koppelvlak bestaan in die kernel, maar die platform se VPN-keuse, per-app-roetering, altyd-aan-beleid en lewensiklus weet niks daarvan nie, en die daemon se eie roete- en DNS-veranderinge kompeteer met die netwerkbestuurder om dieselfde tabelle.

Die gevolg is ’n verbinding wat vir die daemon se verkeer werk en raaiselagtig nie vir die app waarvoor jy omgee nie, of een wat bly totdat die stelsel sy netwerke herbeoordeel. Nie een uitkoms is ’n platformfout nie; dit is die grens tussen ’n soket besit en die VPN-gerief besit.

Hoe die ondersteunde roetes lyk

As die organisasie na ’n profiel kan skuif wat Android self voorsien, is die platformpad die eerlike een. Vanaf API 30, VpnManager ondersteun die voorsiening en beheer van platform-VPN-profiele deur apps, met ’n magtigingswerkvloei gekoppel aan die app wat dit aanroep. Dit is nie ’n L2TP-omsetter nie: die profielmodel wat dit vir IKEv2 voorsien, vertaal nie ’n bestaande L2TP-konfigurasie nie, en om protokol te verander is ’n migrasie, nie ’n hernoeming nie. Identiteite, roetes, private DNS en toegangregte moet doelbewus oorgedra word.

As die diens op L2TP/IPsec moet bly, is die ondersteunde kombinasie ’n kliënt en OS-weergawe wat die operateur werklik dokumenteer, plus sy outomatiseringskontrak as daar een is. Wanneer daar geen gedokumenteerde onbewaakte beheer is nie, is die korrekte antwoord ’n ondersteunde handmatige verbinding eerder as ’n bros bevoorregte skrip wat toevallig op een bou werk.

Wat ’n korrekte outomatisering doen

Met ’n gedokumenteerde beheer het die outomatisering ’n klein en verdedigbare taak: vra die genoemde verbinding aan, wag op gereedheid, stop by mislukking van verifikasie of opstelling, voer die beoogde werk uit, en laat opruiming aan die komponent wat die verbinding besit. Aanmeldgegewens bly by die kliënt wat weet hoe om hulle te stoor en te roteer.

Skryf neer watter komponent elke laag besit voordat jy die eerste reël skryf, en toets die uitslag daarteen:

• IPsec en PPP word deur die kliënt hanteer, nie deur die skrip se roetes nie.
• Die verbinding verskyn in die platform se VPN-toestand, sodat per-app-omvang en altyd-aan daarop geld.
• Geen interne diensoproep, transaksienommer of geraaide argument dra ’n aanmeldgegewens nie.
• Mislukking by enige stap laat geen halfgeregistreerde profiel agter nie.