Automazione L2TP su Android: uno script può richiederla, non crearla

Il mito è che L2TP su Android sia un'altra cosa che uno script shell può avviare: aggiungi una rotta, chiama il vecchio servizio, fatto. Non può essere, perché quattro livelli diversi devono accordarsi prima che un tunnel trasporti un pacchetto. Il livello IPsec protegge il percorso, L2TP trasporta la sessione, PPP negozia il collegamento e Android deve registrare il risultato come una VPN attorno a cui può instradare. L'ho visto tentare due volte con comandi copiati, ed entrambe le volte la rotta esisteva mentre nulla era cifrato.

Cosa ottiene davvero un cambio di rotta

Aggiungere una rotta decide dove va un pacchetto dopo. Non negozia un'associazione di sicurezza, non apre una sessione L2TP e non esegue lo scambio PPP che produce un indirizzo, un peer e le impostazioni DNS. Su un telefono il risultato visibile è traffico che esce dal percorso sbagliato, o che esce e muore, senza alcuno stato di tunnel da nessuna parte.

Lo stesso vale per una chiamata di servizio copiata da una versione precedente. L'impianto VPN interno di Android non è un'API di automazione pubblicata, e una transazione numerata di un'altra versione può colpire un'operazione diversa o richiedere privilegi che lo script non ha. Un'automazione che trasporta una password non dovrebbe mai dipendere da argomenti interni indovinati, perché la modalità di guasto è o un no-op silenzioso o un profilo creato a metà che nessuno ripulisce.

Quattro proprietari, e lo script non è nessuno di loro

Prendili in ordine. IPsec stabilisce e mantiene il percorso protetto e autentica i peer. L2TP trasporta la sessione sopra di esso, e la stratificazione è il motivo per cui lo standard li tratta come meccanismi separati anziché come un unico protocollo. Al suo interno, PPP negozia i parametri di collegamento che il client userà. Android possiede poi il lato piattaforma: l'interfaccia VPN registrata, l'ambito per app, lo stato always-on e il ciclo di vita che decide cosa succede quando l'app viene uccisa.

Uno script può vedere solo l'ultimo di questi livelli, e di solito indirettamente. Può chiedere a un client di connettersi se quel client espone un controllo documentato, e può osservare dopo lo stato dell'interfaccia. Non può sostituire i tre livelli sottostanti, e non può far sì che la piattaforma tratti un'interfaccia non registrata come una VPN.

Perché nemmeno un demone è una scorciatoia

Avviare un demone Linux privilegiato sul dispositivo sembra il pezzo mancante, e spesso tira davvero su un tunnel. Ciò che non fa è registrare quel tunnel con Android. L'interfaccia esiste dentro il kernel, ma la selezione VPN della piattaforma, l'instradamento per app, la policy always-on e il ciclo di vita non la conoscono, e le modifiche a rotta e DNS del demone stesso competono con il gestore di rete per le stesse tabelle.

Il risultato è una connessione che funziona per il traffico del demone e misteriosamente non per l'app che ti interessava, o una che sopravvive finché il sistema non rivaluta le sue reti. Nessuno dei due esiti è un bug della piattaforma; è il confine tra possedere un socket e possedere la funzione VPN.

Che aspetto hanno i percorsi supportati

Se l'organizzazione può passare a un profilo che Android stessa fornisce, il percorso della piattaforma è quello onesto. Dall'API 30, VpnManager supporta il provisioning e il controllo dei profili VPN della piattaforma da parte delle app, con un flusso di autorizzazione legato all'app chiamante. Non è un convertitore L2TP: il modello di profilo che fornisce per IKEv2 non traduce una configurazione L2TP esistente, e cambiare protocollo è una migrazione, non una rinomina. Identità, rotte, DNS privato e permessi di accesso devono essere trasferiti di proposito.

Se il servizio deve restare L2TP/IPsec, la combinazione supportata è un client e una versione di OS che l'operatore documenta davvero, e il suo contratto di automazione se esiste. Quando non c'è un controllo non presidiato documentato, la risposta corretta è una connessione manuale supportata, non uno script privilegiato fragile che capita di funzionare su una build.

Cosa fa un'automazione corretta

Dato un controllo documentato, l'automazione ha un compito piccolo e difendibile: richiedere la connessione nominata, attendere la prontezza, fermarsi su un fallimento di autenticazione o configurazione, eseguire il carico di lavoro previsto e lasciare la pulizia al componente che possiede la connessione. Le credenziali restano con il client che sa come archiviarle e ruotarle.

Annota quale componente possiede ogni livello prima di scrivere la prima riga, e verifica il risultato rispetto a questo elenco:

• IPsec e PPP sono gestiti dal client, non dalle rotte dello script.
• La connessione appare nello stato VPN della piattaforma, quindi l'ambito per app e l'always-on si applicano ad essa.
• Nessuna chiamata di servizio interna, numero di transazione o argomento indovinato trasporta una credenziale.
• Un fallimento in qualsiasi passaggio non lascia un profilo mezzo registrato.