Che cos’è un tunnel VPN e dove finisce la protezione

Il client dice connesso, il lucchetto è chiuso, e un sito registra ancora l’indirizzo del tuo appartamento. Nulla è fallito. Un tunnel non sostituisce il Wi-Fi né il collegamento mobile; mette una seconda busta intorno a determinati pacchetti e spedisce quella busta sulla rete che avevi già. Capire il trucco significa soprattutto seguire una richiesta e notare dove la busta viene aperta, perché quasi ogni sintomo confuso, da un indirizzo di casa che trapela a un grande download bloccato, viene da quel confine.

Due buste, un collegamento fisico

Il portatile mantiene la sua normale connessione al router, e il router mantiene la sua normale connessione al fornitore. Nulla di quel percorso cambia quando si alza un tunnel. Ciò che cambia è che determinati pacchetti vengono consegnati a un’interfaccia virtuale, avvolti in un nuovo pacchetto indirizzato al peer VPN e inviati come traffico ordinario sul collegamento fisico.

L’estremità ricevente è un dispositivo che apre la busta e inoltra il pacchetto originale verso la sua destinazione. Tra le due estremità, un osservatore vede l’intestazione esterna e nulla di quella interna, a meno che il protocollo non la cifri, cosa che fanno la maggior parte dei protocolli consumer e che la tecnica generale non richiede.

Per questo l’interfaccia virtuale è insieme reale e ingannevole. Esiste come oggetto del kernel con un indirizzo e un’unità massima di trasmissione, e il sistema operativo vi instrada il traffico come verso qualsiasi altra interfaccia. Non è un cavo, e la sua esistenza dimostra solo che un componente è installato. Se il browser la usi lo decidono le rotte, non il fatto che l’interfaccia sia attiva.

Segui una richiesta in viaggio

Scegli una destinazione e chiedi al kernel quale interfaccia userà. Questo unico comando risolve la maggior parte delle discussioni sul fatto che il tunnel faccia qualcosa:

ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0

Se l’output della rotta nomina l’interfaccia del tunnel, il pacchetto sarà incapsulato. Se nomina l’interfaccia fisica, non lo sarà, e nessun riavvio del client cambia questo. Il secondo comando mostra le due interfacce fianco a fianco, ed è così che noti un tunnel salito senza indirizzo o con un indirizzo della famiglia sbagliata.

Poi guarda il primo salto dall’interno della busta e confrontalo con il primo salto dall’esterno:

traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5

Dentro il tunnel il primo salto è l’indirizzo interno del peer, non il tuo router. La cattura sull’interfaccia del tunnel mostra i pacchetti interni, cioè il traffico che l’applicazione crede di inviare. La cattura simultanea sull’interfaccia fisica mostra i pacchetti esterni, e le due insieme sono la dimostrazione più chiara di ciò che un tunnel fa davvero.

Tre indirizzi, e il sito ne vede uno solo

Le persone li confondono continuamente, e la confusione produce falsi rapporti di fuga. Sono campi diversi in intestazioni diverse con durate diverse.

Il numero accanto all’adattatore virtuale è la seconda riga. Non è l’indirizzo che un sito registra, e citarlo come il tuo IP pubblico è semplicemente sbagliato. L’indirizzo che un sito vede è assegnato dall’uscita, e in un tunnel verso una rete privata può non esserci alcuna uscita pubblica, perché la destinazione vive dentro l’organizzazione e non su internet.

Un tunnel tra sedi è lo stesso meccanismo con altre estremità. Due router avvolgono il traffico tra reti, e nessun dispositivo individuale ha un client installato. La busta è identica in principio, il confine amministrativo no.

Dove si apre la busta, e cosa le sopravvive

Il tunnel finisce al suo peer. Se la cifratura propria dell’applicazione arriva più lontano, sopravvive a quel confine, che è il caso normale per HTTPS: la sessione del browser termina al sito, quindi l’uscita inoltra testo cifrato che non può leggere.

Nient’altro sopravvive per impostazione predefinita. Una richiesta non cifrata è leggibile all’uscita esattamente come lo era nel Wi-Fi del bar, e il tunnel non aggiunge una protezione che l’applicazione non ha mai avuto. Allo stesso modo, le regole del firewall e la politica di inoltro dell’uscita decidono cosa succede dopo; una stretta di mano riuscita è un fatto sulla connessione al peer, non sul resto del viaggio.

Il sovraccarico è l’altra conseguenza visibile. Ogni pacchetto porta un’intestazione in più, e il trasporto esterno può aggiungere la sua, così il carico utile per pacchetto si riduce. Su un percorso con unità massima di trasmissione fissa, è esattamente per questo che un tunnel può far passare un ping e bloccare un grande caricamento.

Controlla il percorso che l’applicazione ha davvero preso

L’ultimo passo è confermare l’applicazione specifica, non la macchina in generale. Risolvi la destinazione, guarda la rotta per quell’indirizzo e poi osserva la connessione mentre è aperta:

getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'

Se la rotta nomina il tunnel ma l’elenco dei socket mostra una connessione con un indirizzo sorgente dell’interfaccia fisica, l’applicazione è legata a qualcosa di specifico, oppure un secondo tunnel contende la rotta predefinita. È una questione di routing, e si può rispondere con questi tre output invece che con la schermata di stato del client.

L’architettura di sicurezza RFC 4301 descrive la versione a livello IP di questo incapsulamento per IPsec, e la stessa logica a strati vale per WireGuard e OpenVPN. Una volta che sai indicare il pacchetto interno e il pacchetto esterno come oggetti separati, gran parte del comportamento del tunnel smette di essere misterioso e diventa una tabella di routing che puoi leggere.