L2TP automatizavimas Android: scenarijus gali paprašyti, bet ne sukurti

Mitas yra tas, kad L2TP Android sistemoje yra dar vienas dalykas, kurį shell scenarijus gali paleisti: pridėti maršrutą, iškviesti seną paslaugą, baigta. Taip negali būti, nes keturi skirtingi sluoksniai turi sutarti, kol tunelis perneš paketą. IPsec sluoksnis apsaugo kelią, L2TP perneša sesiją, PPP derasi dėl jungties, o Android turi užregistruoti rezultatą kaip VPN, aplink kurį gali maršrutizuoti. Mačiau tai bandoma du kartus su nukopijuotomis komandomis, ir abu kartus maršrutas egzistavo, kol niekas nebuvo užšifruota.

Ką iš tikrųjų pasiekia maršruto pakeitimas

Maršruto pridėjimas nusprendžia, kur paketas keliaus toliau. Jis nedera dėl saugumo asociacijos, neatidaro L2TP sesijos ir nevykdo PPP mainų, kurie sukuria adresą, partnerį ir DNS nustatymus. Telefone matomas rezultatas yra srautas, kuris išeina neteisingu keliu arba išeina ir miršta, niekur neturint tunelio būsenos.

Tas pats galioja paslaugos iškvietimui, nukopijuotam iš senesnio leidimo. Android vidinė VPN infrastruktūra nėra publikuotas automatizavimo API, o numeruota transakcija iš kitos versijos gali pataikyti į kitą operaciją arba reikalauti privilegijų, kurių scenarijus neturi. Automatizacija, kuri neša slaptažodį, niekada neturėtų priklausyti nuo spėjamų vidinių argumentų, nes gedimo būdas yra arba tylus no-op, arba pusiau sukurtas profilis, kurio niekas nesutvarko.

Keturi savininkai, o scenarijus nėra nė vienas jų

Imkite juos iš eilės. IPsec nustato ir palaiko apsaugotą kelią bei autentifikuoja partnerius. L2TP perneša sesiją virš jo, ir būtent sluoksniavimas yra priežastis, kodėl standartas juos laiko atskirais mechanizmais, o ne vienu protokolu. Jo viduje PPP derasi dėl jungties parametrų, kuriuos naudos klientas. Tada Android valdo platformos pusę: užregistruotą VPN sąsają, taikymo sritį pagal programėlę, always-on būseną ir gyvavimo ciklą, kuris nusprendžia, kas nutinka, kai programėlė užmušama.

Scenarijus gali matyti tik paskutinį iš šių sluoksnių, ir dažniausiai netiesiogiai. Jis gali paprašyti kliento prisijungti, jei tas klientas atskleidžia dokumentuotą valdymą, o vėliau gali stebėti sąsajos būseną. Jis negali pakeisti trijų apatinių sluoksnių ir negali priversti platformos neuregistruotos sąsajos traktuoti kaip VPN.

Kodėl ir daemonas nėra trumpesnis kelias

Privilegijuoto Linux daemono paleidimas įrenginyje atrodo kaip trūkstama dalis, ir dažnai jis tikrai pakelia tunelį. Ko jis nepadaro, tai neužregistruoja to tunelio Android sistemoje. Sąsaja egzistuoja branduolyje, bet platformos VPN pasirinkimas, maršrutizavimas pagal programėlę, always-on politika ir gyvavimo ciklas apie ją nežino, o paties daemono maršruto ir DNS pakeitimai konkuruoja su tinklo tvarkykle dėl tų pačių lentelių.

Rezultatas yra ryšys, kuris veikia daemono srautui ir paslaptingai neveikia programėlės, kuri jums rūpėjo, arba toks, kuris išlieka, kol sistema iš naujo įvertina savo tinklus. Nė vienas rezultatas nėra platformos klaida; tai riba tarp socket valdymo ir VPN galimybės valdymo.

Kaip atrodo palaikomi keliai

Jei organizacija gali pereiti prie profilio, kurį Android teikia pats, platformos kelias yra sąžiningas. Nuo API 30, VpnManager palaiko platformos VPN profilių teikimą ir valdymą programėlių, su autorizacijos srautu, susietu su kviečiančia programėle. Tai nėra L2TP konverteris: profilio modelis, kurį jis teikia IKEv2, neverčia esamos L2TP konfigūracijos, o protokolo keitimas yra migracija, ne pervadinimas. Tapatybės, maršrutai, privatus DNS ir prieigos leidimai turi būti perkelti tyčia.

Jei paslauga turi likti L2TP/IPsec, palaikomas derinys yra klientas ir OS leidimas, kurį operatorius tikrai dokumentuoja, ir jo automatizavimo sutartis, jei tokia yra. Kai nėra dokumentuoto nepriežiūros valdymo, teisingas atsakymas yra palaikomas rankinis ryšys, o ne trapus privilegijuotas scenarijus, kuris atsitiktinai veikia viename kūrinyje.

Ką daro teisinga automatizacija

Turint dokumentuotą valdymą, automatizacija turi mažą ir apginamą darbą: paprašyti įvardyto ryšio, laukti pasirengimo, sustoti autentifikavimo ar sąrankos gedimo atveju, paleisti numatytą darbą ir palikti valymą komponentui, kuris valdo ryšį. Kredencialai lieka pas klientą, kuris moka juos saugoti ir keisti.

Užrašykite, kuris komponentas valdo kurį sluoksnį, prieš rašydami pirmą eilutę, ir patikrinkite rezultatą pagal tai:

• IPsec ir PPP tvarko klientas, o ne scenarijaus maršrutai.
• Ryšys rodomas platformos VPN būsenoje, todėl jam taikoma apimtis pagal programėlę ir always-on.
• Joks vidinis paslaugos iškvietimas, transakcijos numeris ar spėjamas argumentas neneša kredencialų.
• Bet kurio žingsnio gedimas nepalieka pusiau užregistruoto profilio.