Come rilevare un tunnel VPN attivo dal codice su qualsiasi piattaforma
Il tunnel esiste, questa destinazione lo attraversa, o risponde l’estremità remota? Sono tre controlli diversi e tre segnali diversi.
«La VPN è attiva?» sono in realtà tre domande in una sola frase. Quale serva al vostro codice è la prima decisione, ed è quella che la maggior parte delle implementazioni salta. Esiste un tunnel su questo dispositivo, il traffico verso questa destinazione esce attraverso di esso, o l’estremità remota risponde con l’identità che vi aspettate. Scegliete la proprietà, poi scegliete il segnale che la misura e infine dite nel registro quale avete realmente misurato.
Tre proprietà, tre segnali
Compresse su una riga ciascuna, le tre domande hanno tre risposte diverse. La tabella qui sotto è la decisione stessa, non il suo riassunto.
| Property | Signal that answers it | What it still leaves open |
|---|---|---|
| Existence | The platform's own connection state: RAS on Windows, NetworkManager on D-Bus on Linux, scutil on macOS | Tunnels of a type the platform does not manage, which includes most third-party clients |
| Path | A route lookup for the one destination, or a scoped proxy or interface key that names the tunnel | Whether the far end is the peer you trust |
| Identity | An authenticated response from the far end, or a source-address policy applied on the server | Which local interface carried the packets |
Leggete l’ultima riga lentamente. Un host privato che risponde dimostra che qualcosa ha risposto, non che la risposta sia arrivata dal tunnel, e non dice nulla su chi sia dall’altra parte. Se la proprietà che vi serve è il percorso, misurate il percorso.
Esistenza: lo stato proprio della piattaforma
Windows risponde a questo per i profili nativi tramite l’API Remote Access Service. RasEnumConnections elenca ciò che è connesso, RasGetConnectStatus riporta lo stato di una voce e RasGetLinkStatistics aggiunge velocità, contatori di byte ed età della connessione. I limiti sono il punto: OpenVPN, WireGuard e i client dei fornitori non registrano mai una connessione RAS, quindi un tunnel sano di quel tipo mostra un elenco vuoto e un codice ingenuo lo segnala come disattivato.
I desktop Linux espongono la stessa proprietà tramite NetworkManager su D-Bus, dove PropertiesChanged sull’oggetto di connessione VPN trasforma il controllo in un evento e la proprietà State riporta quando il collegamento raggiunge lo stato connesso. Da una shell, nmcli connection show --active legge le stesse informazioni, ed è quello che volete durante il debug. macOS tiene quell’elenco nel framework System Configuration, con scutil come sua vista da riga di comando. Tutte e tre descrivono una connessione gestita dalla piattaforma, e tutte e tre tacciono per un tunnel che non gestisce.
Percorso: dove va davvero il pacchetto
La corrispondenza dei nomi è la scorciatoia a cui tutti ricorrono per prima: enumerate le interfacce, provate la stringa contro tun, tap, ppp o ipsec e prendete un riscontro come prova. È un’euristica, e l’insieme delle interfacce può sembrare lo stesso che qualcosa ci passi o no. Le versioni precedenti di iOS rispondevano così e le successive smisero, perché le interfacce visibili non distinguevano più i due stati.
Ciò che l’ha sostituito lì è il dizionario proxy di sistema. Finché una VPN è connessa, la chiamata alle impostazioni proxy restituisce chiavi limitate alle interfacce legate al tunnel, e senza nulla di connesso il dizionario torna vuoto. È un’affermazione più debole di quanto sembri, perché registra la convinzione del sistema che un tunnel esista, non quale destinazione lo usi.
Android ha la propria versione della trappola: la trasmissione vpn.connectivity raggiunge i ricevitori dichiarati nel manifest su alcune build e i ricevitori registrati a runtime su altre. Trattatela come miglior sforzo e tenete una sonda diretta dietro di essa.
Quando è la destinazione che conta, interrogate la tabella di routing invece dell’elenco degli adattatori. Le euristiche del gateway predefinito si rompono su macchine multi-rete e sui tunnel che installano un proprio gateway.
Identità: sondare l’estremità remota
Un ciclo che invia un’eco ICMP all’estremità remota ogni pochi secondi è il controllo più economico di questo tipo, e fallisce in una direzione utile. Puntatelo a un indirizzo che esiste solo dentro la rete privata, perché uno pubblico risponde su qualsiasi collegamento in uscita funzionante e non dimostra nulla. Dove ICMP è filtrato, una breve connessione TCP alla porta del servizio fa lo stesso lavoro.
Un controllo lato server ha esattamente un segnale a disposizione: l’indirizzo di origine sulla connessione. Mantenere l’inventario degli intervalli è lavoro di manutenzione, e non può separare un tunnel da qualsiasi altra rete che usi per caso lo stesso blocco.
Una politica grossolana può convivere con questo. L’identità no, quindi autenticate il client invece di fidarvi di dove sembrano arrivare i suoi pacchetti.
Registrate la categoria, non il verdetto
Tenete separate le categorie di guasto nel registro: nessuna interfaccia, interfaccia presente ma destinazione irraggiungibile, destinazione raggiungibile ma autenticazione rifiutata. Sono tre proprietari diversi, e ciascuno apre un’indagine diversa.
Ridurle a un solo «VPN giù» manda il rapporto a una squadra che non può risolverlo. La categoria è l’output utile; il verdetto è ciò che lo rende sbagliato.