Android OpenVPN: aggiungere una route privata senza root sul telefono

Ti serve una sottorete privata in più — diciamo 10.60.0.0/24 — che il profilo non include al momento. Su un portatile aggiungeresti una route e andresti avanti. Su Android la VPN è un'app, il dispositivo tun appartiene a quell'app e non c'è una tabella di routing che tu possa modificare senza root. La route deve comunque esistere, ma entra nel profilo che il client carica e funziona solo se l'altro lato è d'accordo. Ecco la modifica, la riconnessione, il lato server e il rollback.

Prima della modifica: cosa può e cosa non può fare una route

Una route risponde a una domanda: quale interfaccia deve portare il traffico verso questa destinazione. Non autorizza nulla. Se il proprietario della rete non ha accettato che questo telefono raggiunga quella sottorete, una route corretta produce una configurazione dall'aspetto corretto e uno scarto silenzioso sul gateway, e passerai l'ora successiva a modificare il file sbagliato.

Ottieni prima quell'accordo, per iscritto se la rete ha un proprietario. Poi annota cosa non stai facendo: non assegni al telefono un indirizzo dentro quella LAN, non cambi il listener del server e non scegli un sito in base al nome host. Sono quattro modifiche diverse e solo la prima è tua.

Modifica il profilo che il client carica davvero

Per un client compatibile che importa normale testo di opzioni OpenVPN, l'aggiunta è una riga:

route 10.60.0.0 255.255.255.0

Aggiungila al corpo del profilo, vicino alle altre direttive di routing, lasciando endpoint, certificati, gestione delle chiavi e righe di verifica dell'operatore esattamente come erano. Non incollare un vecchio esempio intero per prendere in prestito una riga: compressione, percorsi di file assoluti e impostazioni cipher obsolete viaggiano con esso e ti costeranno una sessione di debug separata.

Il passaggio che le persone saltano è la proprietà del file. Se l'app ha importato un profilo, la copia che usa è dell'app, e modificare l'originale scaricato non cambia nulla. Usa l'editor supportato dal client, oppure reimporta il file modificato tramite il percorso di aggiornamento, e conferma il nome del profilo attivo quando esistono più nomi simili. Annota quale hai cambiato.

Se il profilo porta già route-nopull, nessuna route dal server viene installata e ogni prefisso che serve al telefono deve essere elencato esplicitamente. È un progetto legittimo, ma significa che una riga omessa appare esattamente come un rifiuto del server.

Riconnetti e verifica sul dispositivo

Disconnetti prima, poi riconnetti lo specifico profilo che hai modificato invece di lasciare che l'app ripristini l'ultima sessione. Apri il log di connessione e conferma che il client abbia analizzato la nuova riga; una direttiva di route ignorata dall'interfaccia è un esito comune della modifica della copia sbagliata.

Prova la destinazione per indirizzo, non per nome. Un controllo TCP su una porta di servizio nota è più informativo di un ping, perché molti host rispondono a ICMP mentre la porta di servizio è filtrata. Se l'indirizzo risponde e un nome no, hai una questione di resolver e non di routing, e la sezione successiva non è per te.

Qui trovano posto anche due controlli di ambito. La VPN per app significa che una route di indirizzo può esserci mentre l'app con cui stai testando è fuori dall'insieme incluso, quindi testa con un'app che sia davvero dentro. E un prefisso IPv4 non dice nulla sul percorso IPv6; se il servizio è dual-stack, aggiungi la route IPv6 corrispondente o aspettati che il client preferisca un percorso che non intendevi.

Un risultato negativo vale la pena di riconoscerlo presto: se una route full-tunnel copre già 0.0.0.0/0, il prefisso non manca e aggiungerlo di nuovo non cambia nulla. La copertura doppia non ripara un rifiuto lato server né una risposta mancante.

Completa il percorso sul server

Tre cose devono essere vere oltre al telefono. Il gateway ha bisogno di una route verso la destinazione e del permesso di inoltrare la sorgente del telefono verso di essa. La destinazione deve accettare quella sorgente e restituire le risposte attraverso il gateway, oppure il progetto ha bisogno di una traduzione deliberata in uscita. L'opzione route del manuale OpenVPN copre la direttiva lato client; inoltro e routing di ritorno sono impostazioni separate su macchine separate.

Se la destinazione si trova dietro un altro client VPN invece che direttamente dietro il gateway, il server ha bisogno di una iroute per la sottorete di quel peer. Quella direttiva appartiene al server e descrive quale client possiede un prefisso; un telefono non può fornirla dal proprio profilo, e nessuna quantità di modifiche lato client la sostituisce.

Controlla esplicitamente il percorso di ritorno. Una risposta che esce dalla route predefinita invece che dal tunnel produce il classico sintomo a metà apertura: la connessione si stabilisce in una direzione e non torna nulla. La traduzione della sorgente sul gateway è una correzione legittima quando la destinazione non può fare routing di ritorno, ma è una decisione di politica con le sue conseguenze.

Rollback e accettazione

Conserva il profilo precedente prima di modificarlo. Se la modifica peggiora le cose, ripristina quella copia attraverso lo stesso percorso di reimportazione, riconnetti e conferma che il vecchio comportamento torni — questo conferma che hai cambiato ciò che pensavi di cambiare. Un rollback che non ripristina lo stato precedente significa che l'app tiene una terza copia che non hai trovato.

Accetta la modifica quando quattro cose valgono, testate in questo ordine dopo una riconnessione fresca: la destinazione risponde sulla sua porta di servizio, il nome privato si risolve se è atteso, HTTPS valida ancora il nome host previsto e il tutto funziona ancora dopo un riavvio o un passaggio da Wi-Fi a rete cellulare. L'ultimo controllo è quello che intercetta una route che esiste solo finché Android non ristabilisce il tunnel.

• Conferma che il proprietario della rete consenta la destinazione prima di modificare qualsiasi cosa.
• Metti la route nel profilo che il client carica, poi reimporta e riconnetti.
• Verifica tramite porta di servizio, dentro l'ambito per app, per la famiglia di indirizzi giusta.
• Correggi inoltro, routing di ritorno e iroute sul server, non sul telefono.
• Conserva una copia di rollback e ritesta dopo un riavvio.