L’operatore VPN può vedere quali siti visiti?
Un server OpenVPN predefinito registra le sessioni, non gli URL. Confronta i log delle connessioni, la cattura del tunnel e il test di fuga DNS prima di affermare cosa vede l’operatore.
Chiedi cosa può vedere la VPN e la risposta dipende da dove ti trovi nel percorso. A livello di sessione l’operatore ha gli eventi di autenticazione e i conteggi dei byte. A livello di pacchetto ha gli indirizzi di destinazione e le tempistiche. A livello DNS può avere i nomi stessi. Ogni livello risponde a una domanda diversa e nessun interruttore ti sposta dall’uno all’altro.
Definisci il livello prima di fare un’affermazione
La stessa connessione produce registri diversi in ogni punto, e un’affermazione sulla privacy ha senso solo se nomina il punto. Leggi la tabella colonna per colonna: cosa esiste a quel livello, cosa può vedere lì un operatore e cosa quegli stessi registri non possono ancora dire.
| Layer | Visible there | Not visible there |
|---|---|---|
| Session and authentication | Account, client address, start and stop times, assigned address, byte counts | URLs, page content, search terms |
| Forwarded packets | Destination address and port, sizes, timing, often the TLS server name | HTTP path, headers, response body |
| DNS resolver | Queried names and the client that asked | Page content and later requests |
| TLS-terminating proxy | Full request line, headers and body | Nothing, by design |
Leggere un livello come quadro completo è l’inizio sia delle affermazioni esagerate sia del falso senso di sicurezza. Un fornitore che dice di non registrare la navigazione può essere accurato sugli URL e conservare comunque i registri di sessione, e una cattura di pacchetti che mostra solo indirizzi non diventa una cronologia di navigazione senza ricerche inverse e congetture.
Quando valuti una politica, trova la frase che descrive ogni livello. Se la politica non li separa, chiedi quali registri esistono invece di accettare un’affermazione generica sulla crittografia.
Inventario delle sessioni: cosa conserva un server OpenVPN standard
Di serie, un server OpenVPN non cattura il traffico. L’output normale è un inventario delle sessioni: l’account che si è autenticato, l’indirizzo di origine da cui è arrivato, le marche temporali di inizio e fine, l’indirizzo del tunnel assegnato e i totali di byte in ciascuna direzione. È un inventario di sessioni, non un elenco di destinazioni.
Le opzioni di registrazione possono aggiungere dettagli. Un livello di verbosità più alto scrive di più sull’handshake e un file di stato può elencare i client connessi, ma nessuno dei due trasforma il server in un proxy trasparente. Produrre URL richiede di terminare TLS o di eseguire un proxy esplicito, ed entrambe le scelte cambiano l’assetto di fiducia invece di attivare una funzione nascosta.
Per questo la versione accurata dell’affermazione nessun log di navigazione è più stretta di quanto sembri. Il server non conosce la pagina, ma sa che una sessione è esistita e all’incirca quanti dati l’hanno attraversata. Se quel registro di sessione viene conservato, e per quanto, è una questione di politica separata.
I pacchetti interni ed esterni sono prove diverse
La cattura dei pacchetti è il modo per vedere cosa attraversa davvero il tunnel. Sul server, indica l’interfaccia del tunnel e scrivi su un file analizzabile offline:
sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | headQuel file contiene il traffico interno decifrato: l’indirizzo del tunnel del client come sorgente, l’indirizzo di destinazione e la porta, le dimensioni dei pacchetti e le tempistiche. Non contiene il percorso HTTP né il corpo della risposta, a meno che TLS non sia stato terminato da qualche parte, ed è un dato sensibile la cui conservazione è una decisione di politica e non una comodità di debug.
Una cattura sull’interfaccia fisica mostra altro. Lì vedi i pacchetti esterni indirizzati all’endpoint VPN, con il payload cifrato all’interno. Indirizzi non correlati che compaiono in quel file sono normali una volta che esiste un adattatore virtuale, perché il dispositivo del tunnel trasporta i flussi interni mentre il trasporto cifrato trasporta quelli esterni.
Chiedi a quale domanda deve rispondere la cattura. L’uso del tunnel da parte di un’applicazione è visibile sull’adattatore virtuale; la raggiungibilità del tunnel verso l’endpoint è visibile su quello fisico. Usare l’uno o l’altro file come quadro completo produce conclusioni che i dati non sostengono.
Il DNS è il punto in cui i nomi diventano visibili
Il DNS resta l’eccezione pratica. Il resolver vede i nomi che gli vengono chiesti di risolvere, quindi chi lo gestisce scopre quali siti cerca un client anche quando le connessioni successive sono cifrate. La cattura del tunnel mostra indirizzi; il resolver mostra nomi.
Verifica quale indirizzo ha usato il resolver per raggiungere un servizio esterno. La risposta è l’indirizzo di uscita del resolver, e confrontarlo con l’uscita VPN dice se la query ha attraversato il tunnel:
dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53Se quell’indirizzo corrisponde alla connessione locale invece che all’uscita del tunnel, la risoluzione ha aggirato la VPN e il nome era visibile sul percorso locale. Ripeti il controllo dopo un aggiornamento del client, perché una nuova versione può cambiare quale resolver installa il profilo.
Il DNS cifrato sposta la visibilità invece di rimuoverla. La rete non vede più la query, ma il resolver sì, e la questione della fiducia cambia semplicemente mano. Il nome del server TLS nell’handshake della connessione è un altro segnale parziale: spesso sopravvive anche quando il payload è opaco, quindi gli indirizzi di destinazione non sono gli unici metadati che un server di inoltro può osservare.
Tre tipi di registro e chi può leggerli
La contabilità delle sessioni, i registri per nome e le prove di fuga sono tre prodotti diversi con tre obblighi diversi. I log di sessione sono economici e poco sensibili, e rispondono a chi si è connesso e quando. I registri per nome richiedono un resolver che registra o un proxy esplicito, e creano un obbligo di informativa verso le persone coinvolte. Le prove di fuga sono un test lato client che confronta ciò che il resolver rivela con l’uscita del tunnel.
Annota quale di questi tre gestisci, chi può leggerlo e quanto resta. Le affermazioni che un servizio non tiene log descrivono un solo livello e restano vere solo entro quell’ambito. Lo stesso fornitore può essere accurato sulle sessioni e sbagliato sul DNS.
Mantieni il test riproducibile: la stessa query al resolver, la stessa interfaccia di cattura e lo stesso confronto. Un’affermazione sulla privacy che non può essere testata a un livello nominato è uno slogan, non un fatto operativo.