Android L2TP automatizazioa: scriptak eskatu dezake, ez eraiki

Mitoa da L2TP Androiden shell script batek abia dezakeen gauza bat gehiago dela: bide bat gehitu, zerbitzu zaharrari deitu, eta kitto. Ezin du horrela izan, lau geruza ezberdinek ados egon behar dutelako tunel batek pakete bat eraman aurretik. IPsec geruzak bidea babesten du, L2TPk saioa eramaten du, PPPk esteka negoziatzen du, eta Androidek emaitza VPN gisa erregistratu behar du, inguruan bideratu ahal izateko. Bi aldiz ikusi dut hau komando kopiatuekin saiatzen, eta bietan bidea bazegoen, ezer zifratuta ez zegoen bitartean.

Zer lortzen duen bide-aldaketak benetan

Bide bat gehitzeak erabakitzen du paketea hurrengo nora joango den. Ez du segurtasun-elkarte bat negoziatzen, ez du L2TP saio bat irekitzen, eta ez du helbide bat, pare bat eta DNS ezarpenak sortzen dituen PPP trukea exekutatzen. Telefono batean ikusgai dagoen emaitza bide okerretik irteten den trafikoa da, edo irten eta hiltzen dena, inongo tunel-egoerarik gabe.

Hori bera gertatzen da bertsio zaharrago batetik kopiatutako zerbitzu-dei batekin. Androiden barneko VPN hoditeria ez da argitaratutako automatizazio-API bat, eta beste bertsio bateko transakzio zenbakitu batek beste eragiketa bat jo dezake edo scriptak ez dituen pribilegioak eska ditzake. Pasahitz bat daraman automatizazioak ez luke inoiz asmatutako barne-argumentuen mende egon behar, huts egiteko modua no-op isila edo inork garbitzen ez duen erdi sortutako profila delako.

Lau jabe, eta scripta ez da horietako bat

Hartu hurrenez hurren. IPsec-ek bide babestua ezartzen eta mantentzen du eta pareak autentifikatzen ditu. L2TPk saioa haren gainean eramaten du, eta geruzatze hori da estandarrak mekanismo bereizi gisa tratatzeko arrazoia, protokolo bakar gisa beharrean. Horren barruan, PPPk bezeroak erabiliko dituen esteka-parametroak negoziatzen ditu. Androidek plataforma aldea du orduan: erregistratutako VPN interfazea, aplikazioko esparrua, always-on egoera eta aplikazioa hiltzean zer gertatzen den erabakitzen duen bizi-zikloa.

Script batek azken geruza hori baino ezin du ikusi, eta normalean zeharka. Bezero bati konektatzeko eskatu ahal dio bezero horrek kontrol dokumentatu bat erakusten badu, eta gero interfazearen egoera begiratu dezake. Ezin ditu azpiko hiru geruzak ordezkatu, ezta plataformak erregistratu gabeko interfaze bat VPN gisa trata dezan lortu.

Zergatik daemon bat ere ez den lasterbidea

Gailuan Linux daemon pribilegiatu bat abiatzeak falta den pieza dirudi, eta askotan tunel bat altxatzen du. Egiten ez duena tunel hori Androidekin erregistratzea da. Interfazea kernelaren barruan dago, baina plataformaren VPN hautaketak, aplikazioko bideratzeak, always-on politikak eta bizi-zikloak ez dakite horretaz, eta daemonaren beraren bide- eta DNS-aldaketek sare-kudeatzailearekin lehiatzen dute taula berberengatik.

Emaitza daemonaren trafikoarentzat funtzionatzen duen eta axola zitzaizun aplikazioarentzat misteriotsuki ez duen konexio bat da, edo sistemak bere sareak berriz ebaluatu arte irauten duen bat. Bi emaitzetako bat ere ez da plataformaren akats bat; socket bat edukitzearen eta VPN instalazioa edukitzearen arteko muga da.

Nolakoak dira onartutako bideak

Erakundeak Androidek berak hornitzen duen profil batera pasa badezake, plataformaren bidea da zintzoa. API 30etik aurrera, VpnManager tresnak plataformako VPN profilen hornikuntza eta kontrola onartzen ditu, deitzen duen aplikazioari lotutako baimen-fluxu batekin. Ez da L2TP bihurtzaile bat: IKEv2rako hornitzen duen profil-ereduak ez du lehendik dagoen L2TP konfigurazio bat itzultzen, eta protokoloa aldatzea migrazioa da, ez izena aldatzea. Identitateak, bideak, DNS pribatua eta sarbide-baimenak nahita eraman behar dira.

Zerbitzuak L2TP/IPsec izaten jarraitu behar badu, onartutako konbinazioa operadoreak benetan dokumentatzen duen bezero eta OS bertsio bat da, eta haren automatizazio-kontratua, baldin badago. Dokumentatutako zaintzarik gabeko kontrolik ez dagoenean, erantzun zuzena onartutako eskuzko konexio bat da, build batean kasualitatez funtzionatzen duen script pribilegiatu hauskor bat baino.

Zer egiten du automatizazio zuzen batek

Kontrol dokumentatu bat emanda, automatizazioak lan txiki eta defendagarria du: izendatutako konexioa eskatu, prest egon arte itxaron, autentifikazio edo konfigurazio hutsegitean gelditu, aurreikusitako karga-lana exekutatu eta garbiketa konexioaren jabe den osagaiari utzi. Kredentzialak gorde eta txandakatu dakien bezeroarekin geratzen dira.

Idatzi zein osagai den geruza bakoitzaren jabe lehenengo lerroa idatzi aurretik, eta egiaztatu emaitza haren aurka:

• IPsec eta PPP bezeroak kudeatzen ditu, ez scriptaren bideek.
• Konexioa plataformaren VPN egoeran agertzen da, beraz aplikazioko esparrua eta always-on aplikatzen zaizkio.
• Barneko zerbitzu-dei batek, transakzio-zenbaki batek edo asmatutako argumentu batek ez du kredentzialik eramaten.
• Edozein urratsetan huts egiteak ez du erdi erregistratutako profilik uzten.