L2TP:n automatisointi Androidissa: skripti voi pyytää, ei rakentaa

Myytti on, että L2TP Androidissa on vielä yksi asia, jonka shell-skripti voi käynnistää: lisää reitti, kutsu vanhaa palvelua, valmis. Niin ei voi olla, koska neljän eri kerroksen on sovittava ennen kuin tunneli kuljettaa pakettia. IPsec-kerros suojaa polun, L2TP kuljettaa istunnon, PPP neuvottelee linkin, ja Androidin on rekisteröitävä tulos VPN:ksi, jonka ympäri se voi reitittää. Olen nähnyt tätä yritettävän kahdesti kopioituja komentoja käyttäen, ja molemmilla kerroilla reitti oli olemassa, kun mikään ei ollut salattua.

Mitä reitin muutos todella saa aikaan

Reitin lisääminen päättää, minne paketti menee seuraavaksi. Se ei neuvottele suojausturva-assosiaatiota, se ei avaa L2TP-istuntoa eikä suorita PPP-vaihtoa, joka tuottaa osoitteen, vertaiskumppanin ja DNS-asetukset. Puhelimessa näkyvä tulos on liikenne, joka lähtee väärää polkua, tai lähtee ja kuolee, ilman tunnelitilaa missään.

Sama koskee vanhemmasta julkaisusta kopioitua palvelukutsua. Androidin sisäinen VPN-putkitus ei ole julkaistu automaatio-API, ja toisen version numeroitu transaktio voi osua eri toimintoon tai vaatia oikeuksia, joita skriptillä ei ole. Automaatio, joka kuljettaa salasanaa, ei koskaan saisi nojata arvattuihin sisäisiin argumentteihin, koska vikatila on joko hiljainen no-op tai puoliksi luotu profiili, jota kukaan ei siivoa.

Neljä omistajaa, eikä skripti ole niistä yksi

Ota ne järjestyksessä. IPsec perustaa ja ylläpitää suojatun polun ja todentaa vertaiset. L2TP kuljettaa istunnon sen päällä, ja kerrostus on syy siihen, että standardi kohtelee niitä erillisinä mekanismeina eikä yhtenä protokollana. Sen sisällä PPP neuvottelee linkkiparametrit, joita asiakas käyttää. Sitten Android omistaa alustapuolen: rekisteröidyn VPN-rajapinnan, sovelluskohtaisen laajuuden, always-on-tilan ja elinkaaren, joka päättää, mitä tapahtuu, kun sovellus tapetaan.

Skripti näkee vain viimeisen näistä kerroksista, ja yleensä epäsuorasti. Se voi pyytää asiakasta yhdistämään, jos asiakas tarjoaa dokumentoidun ohjauksen, ja se voi seurata rajapinnan tilaa jälkeenpäin. Se ei voi korvata kolmea alempaa kerrosta eikä saada alustaa kohtelemaan rekisteröimätöntä rajapintaa VPN:nä.

Miksi daemonikaan ei ole oikotie

Etuoikeutetun Linux-daemonin käynnistäminen laitteessa näyttää puuttuvalta palaselta, ja usein se tuokin tunnelin pystyyn. Se, mitä se ei tee, on tunnelin rekisteröiminen Androidin kanssa. Rajapinta on olemassa ytimen sisällä, mutta alustan VPN-valinta, sovelluskohtainen reititys, always-on-käytäntö ja elinkaari eivät tiedä siitä, ja daemonin omat reitti- ja DNS-muutokset kilpailevat verkkohallinnan kanssa samoista tauluista.

Tuloksena on yhteys, joka toimii daemonin liikenteelle ja mystisesti ei sovellukselle, josta välitit, tai sellainen, joka säilyy kunnes järjestelmä arvioi verkkonsa uudelleen. Kumpikaan tulos ei ole alustan bugi; se on raja socketin omistamisen ja VPN-ominaisuuden omistamisen välillä.

Millaisilta tuetut reitit näyttävät

Jos organisaatio voi siirtyä profiiliin, jonka Android itse tarjoaa, alustan polku on rehellinen. API 30:stä alkaen VpnManager tukee alustan VPN-profiilien tarjoamista ja hallintaa sovelluksille, ja kutsuvan sovelluksen yhteyteen liittyy valtuutusprosessi. Se ei ole L2TP-muunnin: IKEv2:lle tarjottava profiilimalli ei käännä olemassa olevaa L2TP-kokoonpanoa, ja protokollan vaihtaminen on migraatio, ei uudelleennimeäminen. Identiteetit, reitit, yksityinen DNS ja käyttöoikeudet on siirrettävä tarkoituksella.

Jos palvelun on pysyttävä L2TP/IPsecinä, tuettu yhdistelmä on asiakas ja käyttöjärjestelmäjulkaisu, jonka operaattori todella dokumentoi, sekä sen automaatiosopimus, jos sellainen on. Kun dokumentoitua valvomatonta ohjausta ei ole, oikea vastaus on tuettu manuaalinen yhteys eikä hauras etuoikeutettu skripti, joka sattuu toimimaan yhdessä buildissa.

Mitä oikea automatisointi tekee

Dokumentoidun ohjauksen kanssa automaatiolla on pieni ja puolustettava työ: pyydä nimetty yhteys, odota valmiutta, pysähdy todennus- tai asennusvirheeseen, aja aiottu työkuorma ja jätä siivous yhteyden omistavalle komponentille. Tunnukset pysyvät asiakkaalla, joka osaa tallentaa ja kierrättää ne.

Kirjoita ylös, mikä komponentti omistaa minkäkin kerroksen ennen kuin kirjoitat ensimmäisen rivin, ja tarkista tulos sitä vasten:

• IPsec ja PPP hoitaa asiakas, eivät skriptin reitit.
• Yhteys näkyy alustan VPN-tilassa, joten sovelluskohtainen laajuus ja always-on koskevat sitä.
• Mikään sisäinen palvelukutsu, transaktionumero tai arvattu argumentti ei kuljeta tunnusta.
• Minkä tahansa vaiheen epäonnistuminen ei jätä puoliksi rekisteröityä profiilia.