OpenVPN su Android non aggiunge una route senza indirizzo del tunnel

Il tuo profilo OpenVPN su Android non riesce ad aggiungere una route perché il telefono non ha alcun indirizzo sull'interfaccia virtuale, quindi non c'è nulla verso cui una route possa puntare. Le route rispondono solo a dove devono andare i pacchetti. L'indirizzo del tunnel risponde a chi è il telefono dentro il tunnel, e il client deve fornirne uno prima che l'interfaccia possa esistere. Segui i quattro controlli qui sotto in ordine e fermati al primo fallimento, perché modificare le route prima che l'indirizzo esista nasconde il problema reale.

Leggi l'errore nell'ordine in cui il client lo esegue

Il VpnService.Builder di Android tiene separati i due concetti: addAddress() mette un indirizzo sull'interfaccia che l'app sta costruendo, addRoute() aggiunge un prefisso di destinazione e establish() rifiuta di creare l'interfaccia finché non è stato aggiunto almeno un indirizzo. Un client OpenVPN mappa il profilo e le opzioni inviate dal server esattamente su quelle chiamate, quindi una connessione che non analizza mai un indirizzo non può costruire l'interfaccia affatto.

Ecco perché la riga di log che stai leggendo può nominare una route mentre la causa sta un passo prima. Il client raggiunge la fase della route solo dopo che l'interfaccia esiste; senza indirizzo, la chiamata di route fallisce subito o non viene mai eseguita. Quando il log dice che non riesce ad aggiungere una route, parti dall'indirizzo e non dalla sintassi della route.

Controllo 1: il server mette un indirizzo nella risposta?

Per un servizio OpenVPN instradato l'indirizzo proviene dal pool del server o da un'assegnazione per client, e la topologia decide che forma ha. Su un server OpenVPN 2.4 o successivo, un servizio con topologia a sottorete si presenta così:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Con quella forma il server invia qualcosa come ifconfig 10.8.0.6 255.255.255.0. Un'installazione più vecchia con topology net30 invia invece un indirizzo di peer, per esempio ifconfig 10.8.0.6 10.8.0.5, quindi un profilo spostato tra i due modelli può sembrare corretto pur portando la maschera di rete sbagliata.

Cerca nel log di connessione del client l'insieme delle opzioni inviate. Se non contiene alcuna riga ifconfig, il server non ha mai inviato un indirizzo o il client ha rifiutato l'opzione. Su un server che usa client-config-dir, il file nominato secondo il common name del certificato deve esistere e riportare l'assegnazione:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Controllo 2: il client conserva l'indirizzo che ha ricevuto?

Un filtro troppo ampio è la seconda causa comune. pull-filter esiste in OpenVPN 2.4 e successivi, e quando più filtri corrispondono alla stessa opzione vince l'ultimo che corrisponde, quindi un catch-all finale rimuove l'indirizzo senza errori:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Restringi il filtro all'opzione che vuoi davvero eliminare e lascia stare l'indirizzo:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

Il consiglio di disattivare tutti i pull viene di solito da chi vuole liberarsi di una sola route. route-nopull è l'interruttore più stretto: conserva ifconfig e le altre opzioni inviate mentre rifiuta le route inviate e le opzioni in stile DHCP. Usalo quando è davvero ciò che vuoi, e risolvi la questione dell'indirizzo a parte.

Controllo 3: l'indirizzo è tuo da digitare?

L'indirizzamento manuale è legittimo solo quando l'operatore ti consegna il valore. Se ne digiti uno tu, deve provenire dalla sottorete del client VPN, essere unico tra le sessioni attive e corrispondere alla topologia che il server esegue. Copiare l'indirizzo di un bridge desktop o di un host sulla LAN remota fallisce su entrambi i fronti: il telefono rivendicherebbe un indirizzo che esiste già altrove, e il gateway non avrebbe alcun percorso di ritorno verso di esso.

Il prefisso della LAN remota in una route è una destinazione, mai l'identità del telefono. Una route per 10.60.0.0/24 dice di raggiungere quella rete attraverso il tunnel; non dice nulla su quale indirizzo 10.60.0.x il telefono dovrebbe avere, e il telefono non dovrebbe averne nessuno. Le assegnazioni statiche appartengono al lato server, dove non possono collidere con il pool dinamico.

Due sessioni su una sola identità espongono la stessa collisione. Se lo stesso certificato si connette due volte e il server invia un unico indirizzo fisso a entrambe, la seconda sessione duplica la prima, e la soluzione sono identità separate o assegnazioni separate, non una modifica lato client.

Controllo 4: qualcos'altro occupa lo slot del tunnel?

Android consente un solo servizio VPN attivo alla volta. Un'altra app VPN, o una voce VPN sempre attiva lasciata abilitata per un profilo che non funziona più, può occupare quello slot prima che il tuo client OpenVPN chiami establish(). L'interfaccia allora non compare mai anche se il profilo è valido, quindi disconnetti l'altra VPN, disattiva l'impostazione sempre attiva e riconnettiti prima di toccare il profilo.

Un servizio che pretende il bridging Ethernet è l'altro vicolo cieco. Un'app Android senza root può creare un tunnel IP, non un segmento Ethernet bridged, quindi nessun indirizzo che digiti farà funzionare un server dev tap; l'operatore deve offrire un servizio instradato. Quando segnali il problema, includi nome e versione del client, l'insieme delle opzioni inviate, la topologia e il passo esatto in cui l'indirizzo sarebbe dovuto comparire.

Se tutti e quattro i controlli passano e l'indirizzo è presente, unico e correttamente mascherato, la questione della route diventa quella ordinaria: quali prefissi il server autorizza e come il client deve delimitarli. Annota l'indirizzo del tunnel, la sua maschera di rete e la topologia prima di cambiare qualsiasi altra cosa, perché sono quei tre valori che l'operatore deve confrontare con la vista del server.