Android L2TP automatizacija: skripta može zatražiti, ne izgraditi

Mit je da je L2TP na Androidu još jedna stvar koju skripta može pokrenuti: dodaj rutu, pozovi staru uslugu, gotovo. Ne može, jer se četiri sloja moraju složiti prije nego tunel prenese paket. IPsec štiti put, L2TP nosi sesiju, PPP pregovara vezu, a Android rezultat mora registrovati kao VPN. Vidio sam dva pokušaja s kopiranim komandama i oba puta ruta je postojala dok ništa nije bilo šifrovano.

Šta promjena rute zaista postiže

Dodavanje rute odlučuje kuda paket ide dalje. Ne pregovara sigurnosnu asocijaciju, ne otvara L2TP sesiju i ne izvodi PPP razmjenu koja daje adresu, partnera i DNS postavke. Na telefonu ostaje saobraćaj koji izlazi pogrešnim putem ili izlazi i umire, bez stanja tunela.

Isto vrijedi za poziv usluge kopiran iz starijeg izdanja. Androidova unutrašnja VPN infrastruktura nije objavljeni API za automatizaciju, a numerisana transakcija iz druge verzije može pogoditi drugu operaciju ili tražiti privilegije koje skripta nema. Automatizacija koja nosi lozinku ne smije zavisiti od pogađanih argumenata, jer kvar je ili tiho nečinjenje ili napola stvoren profil koji niko ne čisti.

Četiri vlasnika, a skripta nije nijedan

IPsec uspostavlja i održava zaštićeni put i autentifikuje partnere. L2TP nosi sesiju preko njega i zato standard njih tretira kao odvojene mehanizme, a ne kao jedan protokol. PPP pregovara parametre veze koje će klijent koristiti. Android posjeduje stranu platforme: registrovani VPN interfejs, obuhvat po aplikacijama, stanje stalne uključenosti i životni ciklus koji odlučuje šta se dešava kad se aplikacija ubije.

Skripta vidi samo posljednji sloj i to posredno. Može zamoliti klijenta da se poveže ako nudi dokumentovanu kontrolu, i pratiti stanje interfejsa. Ne može zamijeniti tri sloja ispod i ne može natjerati platformu da neregistrovani interfejs tretira kao VPN.

Zašto ni demon nije prečica

Privilegovani Linux demon na uređaju izgleda kao dio koji nedostaje i često podiže tunel. Ali ne registruje taj tunel u Androidu. Interfejs postoji u kernelu, ali izbor VPN-a, usmjeravanje po aplikacijama, politika stalne uključenosti i životni ciklus ne znaju za njega, a demonove promjene ruta i DNS-a takmiče se sa mrežnim menadžerom za iste tabele.

Rezultat je veza koja radi za demonov saobraćaj i misteriozno ne radi za aplikaciju do koje vam je stalo, ili preživi dok sistem ponovo ne procijeni mreže. Nijedan ishod nije greška platforme; to je granica između posjedovanja socketa i VPN mogućnosti.

Kako izgledaju podržani putevi

Ako organizacija može preći na profil koji Android sam obezbjeđuje, put platforme je pošten. Od API 30, VpnManager podržava obezbjeđivanje i kontrolu platformskih VPN profila iz aplikacija, sa tokom autorizacije vezanim za aplikaciju koja poziva. Nije L2TP konvertor: model profila za IKEv2 ne prevodi postojeću L2TP konfiguraciju, a promjena protokola je migracija, ne preimenovanje. Identiteti, rute, privatni DNS i dozvole pristupa moraju se namjerno prenijeti.

Ako usluga mora ostati na L2TP/IPsec, podržana kombinacija je klijent i izdanje OS-a koje operater zaista dokumentuje, i ugovor o automatizaciji ako postoji. Bez dokumentovane kontrole bez nadzora, tačan odgovor je podržana ručna veza, a ne krhka privilegovana skripta koja slučajno radi na jednoj gradnji.

Šta radi ispravna automatizacija

Uz dokumentovanu kontrolu, automatizacija ima mali i odbranjiv posao: zatraži imenovanu vezu, sačekaj spremnost, zaustavi se na neuspjehu autentifikacije ili postavljanja, obavi predviđeni rad i ostavi čišćenje komponenti koja posjeduje vezu. Vjerodajnice ostaju kod klijenta koji zna kako ih čuvati.

Zapišite koja komponenta posjeduje svaki sloj prije prvog reda, i provjerite rezultat prema tome:

• IPsec i PPP obrađuje klijent, ne rute skripte.
• Veza se pojavljuje u VPN stanju platforme, pa se obuhvat po aplikacijama i stalna uključenost primjenjuju.
• Nijedan unutrašnji poziv, broj transakcije ili pogađani argument ne nosi vjerodajnice.
• Neuspjeh u bilo kojem koraku ne ostavlja napola registrovan profil.