Automatització de L2TP a Android: l@APOS@script pot demanar, no construir

El mite és que L2TP a Android és una cosa més que un script pot engegar: afegeix una ruta, crida el servei antic, fet. No pot ser, perquè quatre capes diferents han de posar-se d’acord abans que un túnel porti un paquet. IPsec protegeix el camí, L2TP porta la sessió, PPP negocia l’enllaç i Android ha de registrar el resultat com una VPN per la qual pugui encaminar. Ho he vist intentar dues vegades amb ordres copiades, i les dues vegades la ruta existia mentre no hi havia res xifrat.

Què aconsegueix realment un canvi de ruta

Afegir una ruta decideix on va el paquet després. No negocia una associació de seguretat, no obre una sessió L2TP i no executa l’intercanvi PPP que produeix una adreça, un parell i paràmetres de DNS. En un mòbil, el resultat visible és trànsit que surt pel camí equivocat, o que surt i mor, sense cap estat de túnel.

El mateix passa amb una crida de servei copiada d’una versió anterior. La fontaneria VPN interna d’Android no és una API d’automatització publicada, i una transacció numerada d’una altra versió pot colpejar una operació diferent o exigir privilegis que l’script no té. Una automatització que porta una contrasenya no hauria de dependre mai d’arguments interns endevinats, perquè el mode de fallada és un no-res silenciós o un perfil mig creat que ningú neteja.

Quatre propietaris, i l’script no és cap d’ells

IPsec estableix i manté el camí protegit i autentica els parells. L2TP hi porta la sessió, i aquesta estratificació és la raó per la qual l’estàndard els tracta com a mecanismes separats i no com un sol protocol. A dins, PPP negocia els paràmetres d’enllaç que farà servir el client. Després Android posseeix la banda de plataforma: la interfície VPN registrada, l’abast per aplicació, l’estat sempre actiu i el cicle de vida que decideix què passa quan es mata l’aplicació.

Un script només pot veure l’última d’aquestes capes, i normalment de manera indirecta. Pot demanar a un client que es connecti si aquest client exposa un control documentat, i després observar l’estat de la interfície. No pot substituir les tres capes de sota, ni pot fer que la plataforma tracti una interfície no registrada com una VPN.

Per què un dimoni tampoc no és una drecera

Engegar un dimoni Linux amb privilegis al dispositiu sembla la peça que falta, i sovint sí que aixeca un túnel. El que no fa és registrar aquest túnel a Android. La interfície existeix dins del nucli, però la selecció de VPN, l’encaminament per aplicació, la política sempre activa i el cicle de vida no en saben res, i els canvis de ruta i DNS del dimoni competeixen amb el gestor de xarxa per les mateixes taules.

El resultat és una connexió que funciona per al trànsit del dimoni i misteriosament no per a l’aplicació que t’importava, o una que sobreviu fins que el sistema reavalua les seves xarxes. Cap dels dos resultats no és un error de la plataforma; és la frontera entre posseir un sòcol i posseir la instal·lació de VPN.

Com es veuen els camins suportats

Si l’organització pot passar a un perfil que Android subministra ell mateix, el camí de la plataforma és l’honest. Des de l’API 30, VpnManager admet el subministrament i control de perfils VPN de plataforma per part d’aplicacions, amb un flux d’autorització lligat a l’aplicació que crida. No és un convertidor de L2TP: el model de perfil que subministra per a IKEv2 no tradueix una configuració L2TP existent, i canviar de protocol és una migració, no un canvi de nom. Les identitats, les rutes, el DNS privat i els permisos d’accés s’han de traslladar deliberadament.

Si el servei ha de quedar-se en L2TP/IPsec, la combinació suportada és un client i una versió de sistema que l’operador documenti de debò, i el seu contracte d’automatització si existeix. Quan no hi ha control desatès documentat, la resposta correcta és una connexió manual suportada i no un script fràgil amb privilegis que casualment funciona en una compilació.

Què fa una automatització correcta

Amb un control documentat, l’automatització té una feina petita i defensable: demanar la connexió anomenada, esperar que estigui a punt, aturar-se si falla l’autenticació o la configuració, fer la feina prevista i deixar la neteja al component que posseeix la connexió. Les credencials es queden amb el client que sap com desar-les i rotar-les.

Anota quin component posseeix cada capa abans d’escriure la primera línia, i comprova el resultat contra això:

• IPsec i PPP els gestiona el client, no les rutes de l’script.
• La connexió apareix a l’estat de VPN de la plataforma, així que l’abast per aplicació i el sempre actiu s’hi apliquen.
• Cap crida de servei interna, número de transacció o argument endevinat no porta credencials.
• Una fallada en qualsevol pas no deixa cap perfil mig registrat.