Server VPN su Android: root non rende il telefono raggiungibile
Tre problemi distinti decidono se un telefono può servire client VPN: il percorso in ingresso, il modello di privilegi e l'inoltro. Root tocca solo quello centrale.
Root cambia quali operazioni di rete un processo può tentare. Non dà al telefono un indirizzo raggiungibile pubblicamente, non riserva una mappatura in ingresso presso l'operatore e non mantiene vivo un demone dopo un riavvio. Se stai decidendo se un telefono Android può agire come server VPN, separa tre domande: il client previsto può davvero raggiungere il listener, quale modello di privilegi richiede l'implementazione del server e che cosa va inoltrato una volta che il tunnel è attivo.
Chi deve raggiungere il telefono, e da dove
Un client sulla stessa LAN consentita e un client su dati mobili stanno provando due reti diverse. Stabilisci prima quella prevista, perché le risposte non si trasferiscono. Su Wi-Fi, il traffico in ingresso non sollecitato di solito richiede una mappatura sul router a monte e un percorso pubblico utilizzabile oltre esso. Sul cellulare, il NAT di livello operatore significa che l'IPv4 in ingresso spesso non è disponibile, qualunque cosa il telefono consenta.
Proprio quest'ultimo punto è quello che root non può toccare. Il firewall locale del telefono e il NAT dell'operatore sono sistemi diversi, e cambiare il primo non ha effetto sul secondo. Un indirizzo di interfaccia privato, un'icona dei dati mobili o un socket in ascolto non sono prova di raggiungibilità. Se il percorso dell'operatore offre comunque IPv6 instradabile globalmente, serve ancora una politica deliberata di listener e firewall per esso; avere un indirizzo non è lo stesso che accettare connessioni.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
Servire e inoltrare sono due successi diversi
Un handshake VPN completato dimostra che il tunnel esiste. Non dimostra che il client possa raggiungere una LAN dietro il telefono, né che il telefono possa fungere da uscita internet. Sono configurazioni separate, costruite sul piano degli indirizzi interni, sulle rotte, sul comportamento di ritorno e su una politica di inoltro ristretta per il compito che vuoi davvero.
La modalità di guasto è prevedibile: l'handshake riesce, il client mostra connesso e non si carica nulla. Prima di fare debug del client, decidi quale dei due ruoli stai costruendo. L'accesso remoto a un dispositivo sulla rete del telefono e l'uscita internet a tunnel completo richiedono regole di inoltro diverse, e concederle entrambe quando ne volevi una amplia l'esposizione senza aggiungere la capacità richiesta.
Il modello di privilegi è una scelta, non root o niente
Un demone OpenVPN convenzionale che usa un dispositivo TUN del kernel richiede le capacità corrispondenti, l'accesso al nodo del dispositivo e la collaborazione della politica di sicurezza di Android. Root non è un'esenzione generale da SELinux; un processo privilegiato resta vincolato dalla politica della piattaforma. Per questo un binario che gira tranquillamente su un server Linux può fallire su un telefono senza un errore evidente sui permessi.
Un'implementazione gateway nello spazio utente può avere un modello di privilegi del tutto diverso, quindi l'affermazione comune che ogni server VPN su Android richieda root è troppo ampia. Ciò che root ti compra è la capacità di tentare più operazioni, non la garanzia che siano consentite o che il risultato sia raggiungibile.
La registrazione del servizio VPN di Android è ancora un altro meccanismo. Dà a un'app un'interfaccia client gestita con un ciclo di vita definito; non è un installatore di server generico, e avviare un demone da un terminale non gli dà gestione sempre attiva, criteri per app o un percorso di ripristino proprio.
Se vuoi un punto di uscita, cambia l'architettura
Quando l'obiettivo è semplicemente un'uscita internet remota attraverso il telefono invece della compatibilità con un profilo OpenVPN esistente, un nodo di uscita supportato in una rete overlay è il progetto più adatto. Tailscale documenta un ruolo di nodo di uscita Android con i propri passaggi di registrazione, autorizzazione e selezione del client.
Lo scambio è reale e va detto chiaramente: accetti un protocollo diverso, un modello di fiducia diverso e una dipendenza da quell'account e servizio di coordinamento. Non fa entrare nella rete overlay un client OpenVPN non modificato, e non ti dà un listener OpenVPN su un indirizzo pubblico.
Che cosa serve ancora al deployment
Qualunque strada scegli, le basi operative decidono se sopravvive una settimana. Mantieni private le credenziali del server, emetti identità client distinte e pianifica la revoca prima di averne bisogno. Decidi come arrivano gli aggiornamenti, che cosa tiene il servizio in funzione in background e come si riprende dopo un riavvio o un cambio di rete.
Evita le scorciatoie che sembrano comode: un binario statico obsoleto, nomi di interfaccia codificati a mano e uno script di avvio che svuota la politica del firewall esistente. Poi accetta il risultato solo davanti a un test concreto: un client remoto autorizzato raggiunge la risorsa prevista, le destinazioni vietate restano non disponibili e il dispositivo torna da solo dopo l'evento di ciclo di vita supportato. L'accesso root è un ingrediente possibile di quel risultato, e raramente quello decisivo.