Trafik på eth0 betyder ikke, at VPN-tunnelen lækker

At se offentlige adresser på eth0, mens tunnelen er oppe, føles som bevis på, at noget er sluppet ud. Som regel er det omvendt: tunnellens egne pakker skal krydse den adapter for at nå serveren, og de ligner almindelige UDP- eller TCP-strømme. Den indre pakke vises kun på tunneleenheden. At skelne de to er et spørgsmål om at læse indpakningen, ikke om at stole på et bytetal.

Hver tunnelpakke krydser stadig ledningen

En tunnel er en grænseflade, ikke en ledning. Klienten tager en indre pakke, pakker den ind og sender resultatet til serverens adresse og port fra profilen. På den fysiske adapter ser du indpakningen; på tunneleenheden ser du det, der blev pakket ind.

I UDP-tilstand er den ydre strøm ét adresse- og portpar i hver retning, og derfor ser en sund tunnel næsten kedelig ud på eth0. Netop det ene par er det første, du skal lede efter.

Optag én grænseflade ad gangen

Optag én grænseflade ad gangen, når du vil sammenligne antal. Pseudo-grænsefladen any samler alle enheder på én gang, så en videresendt pakke vises ved indgang og udgang, og en lokalt genereret vises to gange i to forskellige former. Lige pakkeantal med ulige byteantal er normalt, fordi indpakningen er større end det, den bærer. ARP, DHCP og IPv6-routermeddelelser hører til det lokale led og siger intet om din applikation.

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

Erstat adressen og porten med profiliens egne værdier. Hvis den strøm er stabil, bærer tunnelen noget.

Spørg kernen, hvilken enhed den vælger

Spørg kernen, hvilken enhed den ville vælge, og bekræft det derefter på ledningen. Ruteopslaget er beslutningen, og optagelsen er beviset for, at beslutningen blev fulgt. De svarer på forskellige spørgsmål, og du vil have begge.

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

Et delt resultat er det almindelige fund: IPv4 går til tunnelen, og IPv6 går til den fysiske adapter, fordi profilen kun skubbede IPv4-ruter. Det er en reel lækage, og den er usynlig i en optagelse, der kun dækker IPv4. Filtrer på IPv6, og hold øje med adresser, som ikke er serveren og ikke er link-local.

Kør begge opslag før og efter forbindelsen, så du kan se, hvad klienten faktisk ændrede. Forskellen mellem de to kørsler er klientens reelle effekt.

Når optagelsen virkelig er en lækage

Nogle gange taler optagelsen sandt. En snævrere rute, der sender et præfiks uden om tunnelen, et undernet, som klienten blev bedt om at udelukke, eller en firewall-tilladelse, der kører før tunnelpolitikken, kan alle sætte trafik på ledningen i klartekst. En regel, der matcher en procesgruppe, kan også være en bevidst undtagelse. Læs dens grænseflade og destinationsomfang, før du kalder det en fejl.

Ret ruten eller undtagelsen, ikke firewallen. Optag derefter igen fra en ny forbindelse, og kontrollér IPv4 og IPv6 hver for sig, fordi en rettelse af det ene intet siger om det andet. tcpdump-manualen dækker de grænseflade- og retningsvælgere, der blev brugt ovenfor.