Android L2TP aŭtomatigo: skripto povas peti, ne konstrui

La mito estas, ke L2TP en Android estas ankoraŭ unu afero, kiun skripto povas startigi: aldonu itineron, voku la malnovan servon, preta. Tio ne eblas, ĉar kvar malsamaj tavoloj devas interkonsenti antaŭ ol tunelo portos paketon. IPsec protektas la vojon, L2TP portas la sesion, PPP intertraktas la ligon, kaj Android devas registri la rezulton kiel VPN, ĉirkaŭ kiu ĝi povas itinerigi. Mi vidis tion dufoje kun kopiitaj komandoj, kaj ambaŭfoje la itinero ekzistis dum nenio estis ĉifrita.

Kion itinera ŝanĝo efektive atingas

Aldoni itineron decidas, kien la paketo iros poste. Ĝi ne intertraktas sekurecan asocion, ne malfermas L2TP-sesion, kaj ne faras la PPP-interŝanĝon, kiu donas adreson, partneron kaj DNS-agordojn. Sur telefono la videbla rezulto estas trafiko, kiu eliras per la malĝusta vojo, aŭ eliras kaj mortas, sen ia tunela stato.

La samo validas por servovoko kopiita el pli malnova eldono. La interna VPN-infrastrukturo de Android ne estas publikigita aŭtomatiga API, kaj numerita transakcio el alia versio povas trafi alian operacion aŭ postuli privilegiojn, kiujn la skripto ne havas. Aŭtomatigo, kiu portas pasvorton, neniam fidu je divenitaj internaj argumentoj, ĉar la misfunkcio estas aŭ silenta nenio aŭ duone kreita profilo, kiun neniu purigas.

Kvar posedantoj, kaj la skripto estas neniu el ili

Prenu ilin laŭvice. IPsec starigas kaj konservas la protektitan vojon kaj aŭtentikigas la partnerojn. L2TP portas la sesion super ĝi, kaj tiu tavoligo estas la kialo, ke la normo traktas ilin kiel apartajn mekanismojn, ne kiel unu protokolon. Enside PPP intertraktas la ligajn parametrojn, kiujn la kliento uzos. Poste Android posedas la platforman flankon: la registrita VPN-interfaco, la amplekso laŭ aplikaĵo, la stato ĉiam ŝaltita kaj la vivociklo, kiu decidas, kio okazas kiam la aplikaĵo estas mortigita.

Skripto vidas nur la lastan el tiuj tavoloj, kaj kutime nerekte. Ĝi povas peti klienton konektiĝi, se tiu kliento proponas dokumentitan regadon, kaj poste observi la interfacan staton. Ĝi ne povas anstataŭi la tri tavolojn sube, nek igi la platformon trakti neregistritan interfacon kiel VPN.

Kial ankaŭ demono ne estas fuŝvojo

Startigi privilegian Linux-demonon sur la aparato aspektas kiel la mankanta peco, kaj ĝi ofte vere starigas tunelon. Kion ĝi ne faras, estas registri tiun tunelon ĉe Android. La interfaco ekzistas en la kerno, sed la VPN-elekto de la platformo, la itinerigo laŭ aplikaĵo, la politiko ĉiam ŝaltita kaj la vivociklo ne scias pri ĝi, kaj la propraj itinero- kaj DNS-ŝanĝoj de la demono konkurantas kun la retadministrilo por la samaj tabeloj.

La rezulto estas konekto, kiu funkcias por la trafiko de la demono kaj mistere ne por la aplikaĵo, pri kiu vi zorgis, aŭ unu, kiu pluvivas ĝis la sistemo reanalizos siajn retojn. Neniu el ambaŭ rezultoj estas platforma cimo; ĝi estas la limo inter posedi ingon kaj posedi la VPN-instalaĵon.

Kiel aspektas la subtenataj vojoj

Se la organizo povas transiri al profilo, kiun Android mem provizas, la platforma vojo estas la honesta. Ekde API 30, VpnManager subtenas provizadon kaj regadon de platformaj VPN-profiloj fare de aplikaĵoj, kun rajtiga fluo ligita al la vokanta aplikaĵo. Ĝi ne estas L2TP-konvertilo: la profila modelo, kiun ĝi provizas por IKEv2, ne tradukas ekzistantan L2TP-agordon, kaj ŝanĝi protokolon estas migrado, ne renomado. Identecoj, itineroj, privata DNS kaj alirpermesoj devas esti transdonitaj intence.

Se la servo devas resti ĉe L2TP/IPsec, la subtenata kombinaĵo estas kliento kaj OS-eldono, kiujn la funkciigisto vere dokumentas, kaj ĝia aŭtomatiga kontrakto, se ĝi ekzistas. Kiam mankas dokumentita senhoma regado, la ĝusta respondo estas subtenata mana konekto, ne rompiĝema privilegia skripto, kiu hazarde funkcias sur unu konstruo.

Kion faras ĝusta aŭtomatigo

Donita dokumentitan regadon, la aŭtomatigo havas malgrandan kaj defendebleblan taskon: peti la nomitan konekton, atendi pretemon, halti ĉe aŭtentika aŭ agorda malsukceso, plenumi la celitan laboron, kaj lasi la purigadon al la komponanto, kiu posedas la konekton. Akreditaĵoj restas ĉe la kliento, kiu scias kiel konservi kaj rotacii ilin.

Skribu, kiu komponanto posedas ĉiun tavolon antaŭ ol skribi la unuan linion, kaj kontrolu la rezulton kontraŭ tio:

• IPsec kaj PPP estas traktataj de la kliento, ne de la itineroj de la skripto.
• La konekto aperas en la VPN-stato de la platformo, do amplekso laŭ aplikaĵo kaj ĉiam-ŝaltita validas por ĝi.
• Neniu interna servovoko, transakcia numero aŭ divenita argumento portas akreditaĵojn.
• Malsukceso ĉe iu ajn paŝo ne lasas duone registritan profilon.