Un’app Android qualsiasi, usando una manciata di righe di codice, può stabilire se stai usando una VPN e, in alcuni casi, raccogliere informazioni sul vero indirizzo IP uso. Questo comportamento non dipende da una singola falla di sicurezza, bensì da come Android espone alcune informazioni di rete alle app in esecuzione sul dispositivo.
Inutile dire che in molti hanno subito parlato di un importante problema legato alla privacy degli utenti: se un’applicazione Android, opportunamente sviluppata, può raccogliere informazioni sulla configurazione di rete del dispositivo mobile, allora può adattare il suo comportamento di conseguenza.
API di sistema su Android e rilevamento VPN
Android, sin dalle versioni basate sul kernel Linux 3.x, gestisce la connettività tramite interfacce di rete virtuali e fisiche. Con l’introduzione delle API (Application Programming Interfaces) VpnService (Android 4.0 e successive), le VPN non operano come su desktop con un driver di basso livello, ma come un layer applicativo che intercetta il traffico e lo instrada.
È un’architettura che offre massima flessibilità, ma lascia visibili alcune tracce: ogni app può interrogare il sistema tramite classi come ConnectivityManager e NetworkCapabilities.
Il sistema restituisce così dettagli preziosi sulle reti attive: tipo di connessione, stato e presenza di trasporti come WIFI, CELLULAR o VPN. Non serve alcun permesso invasivo per ottenere questi dati: spesso basta ACCESS_NETWORK_STATE.
In pratica, un’app può sapere se è attiva una VPN perché Android segnala esplicitamente il trasporto TRANSPORT_VPN. Non è un bug, è una scelta di design: serve ad esempio per adattare il comportamento dell’app in presenza di reti filtrate o per diagnosticare problemi di connettività.
Indirizzo IP: cosa è realmente visibile alle app
Quando una VPN è attiva, il traffico delle app passa attraverso un’interfaccia virtuale – spesso denominata tun0 – gestita dalla VPN stessa. Le app vedono quindi l’indirizzo IP interno assegnato dalla VPN e non quello pubblico reale.
Esistono però scenari in cui questa separazione non è perfetta: configurazioni di split tunneling, errori nell’implementazione della VPN o gestione incompleta del DNS possono lasciare fuori dal tunnel VPN parte del traffico. In questi casi, un’app può osservare richieste che bypassano la VPN.
Un altro elemento spesso sottovalutato riguarda WebRTC. I componenti che utilizzano WebView (una tecnologia che integra contenuti Web all’interno di un’applicazione) possono appunto sfruttare WebRTC, insieme di protocolli per la comunicazione in tempo reale tra browser, per ottenere informazioni sugli indirizzi IP locali (cioè quelli assegnati alla rete interna del dispositivo) e, in alcuni casi, anche sull’indirizzo IP pubblico (quello visibile su Internet). Non si tratta di un metodo diretto per identificare con certezza l’IP reale dell’utente, ma consente di aumentare la quantità di dati di rete accessibili, ampliando così le informazioni disponibili.
Dal codice open source ai casi reali
Progetti open source come VPN-Detector dimostrano chiaramente come basti interrogare alcune API di sistema per ottenere il riscontro sull’uso di una soluzione VPN ed eventualmente anche sugli indirizzi IP in uso.

Se poi si passa a iniziative più articolate come RKNHardering, il quadro si amplia: non solo rilevamento, ma studio di tecniche per identificare, limitare o aggirare l’uso delle VPN in scenari reali, spesso legati a censura o controllo del traffico. Nati in ambiti dove il controllo del traffico è centrale, RKNHardering analizza pattern di rete, comportamenti delle connessioni e caratteristiche delle VPN.
Il fatto è che non servono privilegi elevati: spesso basta combinare dati apparentemente innocui. Una libreria di analytics, ad esempio, può rilevare la presenza di una VPN e associare questa informazione ad altri indicatori, costruendo un profilo più dettagliato dell’utente.
Va detto però che esistono anche usi legittimi. App bancarie, servizi di streaming e piattaforme enterprise utilizzano il rilevamento della VPN per motivi di sicurezza o per applicare restrizioni geografiche. La stessa funzionalità può quindi avere una valenza difensiva o invasiva, a seconda del caso.
Come funziona RKNHardering
Un’app come RKNHardering fa perno sul VerdictEngine, che aggrega i risultati provenienti da diversi moduli. Tra questi troviamo controlli diretti, indiretti, analisi GeoIP, verifiche di bypass e controlli a basso livello. Un elemento importante: non tutti i moduli contribuiscono allo stesso modo al risultato finale. Alcuni di essi producono solo segnali diagnostici.
Il modulo DirectSignsChecker sfrutta API ufficiali. Tramite ConnectivityManager, verifica la presenza del trasporto VPN con TRANSPORT_VPN e cerca stringhe come IS_VPN o VpnTransportInfo nella rappresentazione delle caratteristiche di rete. Non solo. Controlla anche la configurazione del proxy di sistema attraverso proprietà apposite: se trova un host valido su porte tipiche – ad esempio 1080 o 8080 – segnala un possibile proxy attivo.
Un altro aspetto interessante riguarda le app installate: il sistema interroga il PackageManager per identificare applicazioni che dichiarano VpnService. Questo non prova l’uso attivo di una VPN, ma rappresenta un indizio utile.
La parte più tecnica emerge nel modulo IndirectSignsChecker: l’app analizza le interfacce di rete attive tramite NetworkInterface.getNetworkInterfaces. Pattern come tun, tap, wg o ppp indicano spesso la presenza di un tunnel VPN.
Viene poi esaminata la tabella di routing, usando sia API Android sia il file /proc/net/route. Se la rotta predefinita passa attraverso un’interfaccia non standard, oppure coesistono percorsi tipici di split tunneling, il sistema segnala un’anomalia.
L’utilizzo di una configurazione DNS con server locali come 127.x.x.x o configurazioni incoerenti rispetto alla rete sottostante, rappresentano indicatori forti.
Perché il riferimento alla Russia
Lo sviluppatore di RKNHardering dichiara esplicitamente di aver modellato parte della logica sull’approccio utilizzato da Roskomnadzor, l’autorità russa che supervisiona telecomunicazioni e Internet. In pratica, RKNHardering simula un ambiente di rilevamento pensato per individuare strumenti di aggiramento della censura.
In Russia il blocco dei contenuti avviene spesso a livello di rete e gli utenti ricorrono a VPN, proxy e sistemi come Xray o MTProto per bypassare queste restrizioni. Di conseguenza, anche i meccanismi di rilevamento si sono evoluti: non basta più identificare una singola connessione sospetta, serve correlare più segnali.
RKNHardering replica proprio quell’approccio: ad esempio, combina dati di geolocalizzazione della rete mobile – come MCC e informazioni SIM – con risultati GeoIP ottenuti da servizi esterni.
Evoluzione delle protezioni su Android
Con Android 10 e versioni successive, Google ha introdotto limitazioni più rigide sull’accesso ai dati personali e riservati. Molte API risultano ristrette e l’accesso a identificatori univoci richiede autorizzazioni esplicite.
Nonostante ciò, l’informazione sulla presenza di una VPN attiva resta disponibile: ridurla significherebbe compromettere funzionalità utili per numerose applicazioni.
La percezione che “tutte le app possono vedere la VPN” rischia di semplificare troppo il problema. La vera questione riguarda la correlazione dei dati. Alla fine, se presa da sola, l’informazione sulla VPN ha un impatto limitato; combinata con altri segnali, può diventare significativa.
Mitigazioni e buone pratiche
Chi utilizza una VPN dovrebbe scegliere soluzioni che implementano correttamente il tunneling completo e il controllo del DNS. La presenza di un kill switch è fondamentale: blocca il traffico se la VPN si interrompe, evitando esposizioni accidentali.
È consigliabile evitare lo split tunneling (configurazione che permette a parte del traffico di rete di bypassare la VPN) quando non è indispensabile, perché spesso introduce canali di uscita non protetti che possono esporre i dati a rischi di sicurezza.
Sul versante degli sviluppatori, anche con l’intercessione di Google, sarebbe auspicabile una maggiore trasparenza sull’uso delle informazioni di rete. Non tanto per eliminare la possibilità di rilevare una VPN, quanto per rendere chiaro all’utente come e perché questi dati sono utilizzati. Il confine tra funzionalità e abuso, come spesso accade, non è imposto dal sistema ma da chi scrive il codice.