El trànsit per eth0 no significa que el túnel VPN tingui fuites

Veure adreces públiques a eth0 mentre el túnel és actiu sembla la prova que alguna cosa s’ha escapat. Normalment és el contrari: els paquets del mateix túnel han de travessar aquest adaptador per arribar al servidor, i semblen fluxos UDP o TCP corrents. El paquet interior només apareix al dispositiu del túnel. Distingir-ne els dos és qüestió de llegir l’embolcall, no de confiar en un recompte de bytes.

Cada paquet del túnel encara travessa el cable

Un túnel és una interfície, no un cable. El client agafa un paquet interior, l’embolcalla i envia el resultat a l’adreça i el port del servidor del perfil. A l’adaptador físic veieu l’embolcall; al dispositiu del túnel veieu què s’ha embolcallat.

En mode UDP el flux exterior és una única parella d’adreça i port en cada direcció, i per això un túnel sa sembla gairebé avorrit a eth0. Aquesta parella única és el primer que cal buscar.

Captureu una interfície alhora

Captureu una interfície alhora quan vulgueu comparar recomptes. La pseudointerfície any recull tots els dispositius alhora, de manera que un paquet reenviat apareix a l’entrada i a la sortida i un de generat localment apareix dues vegades en dues formes diferents. Recomptes de paquets iguals amb recomptes de bytes desiguals són normals, perquè l’embolcall és més gran que allò que transporta. L’ARP, el DHCP i els anuncis de router IPv6 pertanyen a l’enllaç local i no diuen res sobre la vostra aplicació.

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

Substituïu l’adreça i el port pels valors del mateix perfil. Si aquest flux és estable, el túnel transporta alguna cosa.

Pregunteu al nucli quin dispositiu tria

Pregunteu al nucli quin dispositiu triaria i després confirmeu-ho al cable. La consulta de ruta és la decisió, i la captura és la prova que la decisió s’ha seguit. Responen preguntes diferents i voleu totes dues.

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

Un resultat dividit és la troballa habitual: IPv4 va al túnel i IPv6 va a l’adaptador físic perquè el perfil només ha empès rutes IPv4. Això és una fuita real, i és invisible en una captura només d’IPv4. Filtreu IPv6 i vigileu les adreces que no són el servidor ni són link-local.

Executeu les dues consultes abans i després de connectar, perquè pugueu veure què ha canviat realment el client. La diferència entre les dues execucions és l’efecte real del client.

Quan la captura sí que és una fuita

De vegades la captura diu la veritat. Una ruta més estreta que envia un prefix per fora del túnel, una subxarxa que s’ha dit al client que exclogui, o una acceptació del tallafoc que s’executa abans de la política del túnel poden posar trànsit al cable en clar. Una regla que coincideix amb un grup de processos també pot ser una excepció deliberada. Llegiu-ne la interfície i l’abast de destinació abans de qualificar-ho de defecte.

Corregiu la ruta o l’exclusió, no el tallafoc. Després torneu a capturar des d’una connexió nova i comproveu IPv4 i IPv6 per separat, ja que arreglar-ne un no diu res de l’altre. El manual de tcpdump cobreix els selectors d’interfície i de direcció emprats més amunt.