Trafikk på eth0 betyr ikke at VPN-tunnelen lekker

Å se offentlige adresser på eth0 mens tunnelen er oppe føles som bevis på at noe har sluppet ut. Som regel er det omvendt: tunnellens egne pakker må krysse den adapteren for å nå serveren, og de ser ut som vanlige UDP- eller TCP-strømmer. Den indre pakken vises bare på tunneleenheten. Å skille de to er et spørsmål om å lese innpakningen, ikke om å stole på et bytetall.

Hver tunnelpakke krysser fortsatt ledningen

En tunnel er et grensesnitt, ikke en ledning. Klienten tar en indre pakke, pakker den inn og sender resultatet til serverens adresse og port fra profilen. På den fysiske adapteren ser du innpakningen; på tunneleenheten ser du det som ble pakket inn.

I UDP-modus er den ytre strømmen ett adresse- og portpar i hver retning, og derfor ser en sunn tunnel nesten kjedelig ut på eth0. Nettopp det ene paret er det første du bør lete etter.

Ta opp ett grensesnitt om gangen

Ta opp bare ett grensesnitt om gangen når du vil sammenligne antall. Pseudogrensesnittet any samler alle enheter på én gang, så en videresendt pakke vises ved inngang og utgang, og en lokalt generert vises to ganger i to ulike former. Like pakketall med ulike bytetall er normalt, fordi innpakningen er større enn det den bærer. ARP, DHCP og IPv6-rutermeldinger hører til den lokale linken og sier ingenting om applikasjonen din.

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

Erstatt adressen og porten med profilens egne verdier. Hvis den strømmen er jevn, bærer tunnelen noe.

Spør kjernen hvilken enhet den velger

Spør kjernen hvilken enhet den ville velge, og bekreft deretter på ledningen. Ruteoppslaget er beslutningen, og opptaket er beviset for at beslutningen ble fulgt. De svarer på ulike spørsmål, og du vil ha begge.

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

Et delt resultat er det vanlige funnet: IPv4 går til tunnelen, og IPv6 går til den fysiske adapteren fordi profilen bare skjøv inn IPv4-ruter. Det er en ekte lekkasje, og den er usynlig i et opptak som bare dekker IPv4. Filtrer på IPv6 og følg med på adresser som ikke er serveren og ikke er link-local.

Kjør begge oppslagene før og etter tilkoblingen, slik at du ser hva klienten faktisk endret. Forskjellen mellom de to kjøringene er klientens reelle effekt.

Når opptaket virkelig er en lekkasje

Noen ganger snakker opptaket sant. En smalere rute som sender ett prefiks utenom tunnelen, et subnett klienten fikk beskjed om å utelate, eller en brannmur-tillatelse som kjører før tunnelpolicyen kan alle sette trafikk på ledningen i klartekst. En regel som matcher en prosessgruppe kan også være et bevisst unntak. Les grensesnittet og destinasjonsomfanget før du kaller det en feil.

Rett på ruten eller unntaket, ikke brannmuren. Ta deretter opp igjen fra en ny tilkobling og kontroller IPv4 og IPv6 hver for seg, fordi en retting av det ene ikke sier noe om det andre. tcpdump-håndboken dekker grensesnitt- og retningsvelgerne som ble brukt ovenfor.