Il traffico su eth0 non significa che il tunnel VPN perda

Vedere indirizzi pubblici su eth0 mentre il tunnel è attivo sembra la prova che qualcosa sia fuggito. Di solito è il contrario: i pacchetti del tunnel stesso devono attraversare quell’adattatore per raggiungere il server, e sembrano flussi UDP o TCP ordinari. Il pacchetto interno compare solo sul dispositivo del tunnel. Distinguere i due è questione di leggere l’involucro, non di fidarsi di un conteggio di byte.

Ogni pacchetto del tunnel attraversa comunque il cavo

Un tunnel è un’interfaccia, non un cavo. Il client prende un pacchetto interno, lo incapsula e invia il risultato all’indirizzo e alla porta del server indicati nel profilo. Sull’adattatore fisico vedete l’involucro; sul dispositivo del tunnel vedete ciò che è stato incapsulato.

In modalità UDP il flusso esterno è un’unica coppia di indirizzo e porta in ciascuna direzione, per questo un tunnel sano sembra quasi noioso su eth0. È proprio quella coppia unica che va cercata per prima.

Catturate un’interfaccia alla volta

Catturate un’interfaccia alla volta quando intendete confrontare i conteggi. La pseudo-interfaccia any raccoglie ogni dispositivo insieme, quindi un pacchetto inoltrato compare all’ingresso e all’uscita e uno generato localmente compare due volte in due forme diverse. Conteggi di pacchetti uguali con conteggi di byte diversi sono normali, perché l’involucro è più grande di ciò che trasporta. ARP, DHCP e gli annunci del router IPv6 appartengono al collegamento locale e non dicono nulla sulla vostra applicazione.

sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194

Sostituite l’indirizzo e la porta con i valori del profilo stesso. Se quel flusso è costante, il tunnel trasporta qualcosa.

Chiedete al kernel quale dispositivo sceglie

Chiedete al kernel quale dispositivo sceglierebbe, poi confermatelo sul cavo. La ricerca della rotta è la decisione, e la cattura è la prova che la decisione è stata seguita. Rispondono a domande diverse e volete entrambe.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Un risultato diviso è il riscontro abituale: IPv4 va al tunnel e IPv6 va all’adattatore fisico perché il profilo ha spinto solo rotte IPv4. Quella è una vera perdita, ed è invisibile in una cattura solo IPv4. Filtrate IPv6 e osservate gli indirizzi che non sono il server e non sono link-local.

Eseguite entrambe le ricerche prima e dopo la connessione, così potete vedere cosa ha cambiato davvero il client. La differenza tra le due esecuzioni è l’effetto reale del client.

Quando la cattura è davvero una perdita

A volte la cattura dice la verità. Una rotta più stretta che manda un prefisso attorno al tunnel, una sottorete che al client è stato detto di escludere, o un’accettazione del firewall che gira prima della policy del tunnel possono tutte mettere traffico sul cavo in chiaro. Anche una regola che corrisponde a un gruppo di processi può essere un’eccezione voluta. Leggete la sua interfaccia e l’ambito di destinazione prima di chiamarla difetto.

Correggete la rotta o l’esclusione, non il firewall. Poi catturate di nuovo da una connessione nuova e controllate IPv4 e IPv6 separatamente, perché correggere l’uno non dice nulla sull’altro. Il manuale di tcpdump descrive i selettori di interfaccia e di direzione usati sopra.