Trafikk på eth0 tyder ikkje at VPN-tunnelen lekk

Å sjå offentlege adresser på eth0 medan tunnelen er oppe kjennest som prov på at noko har sloppe ut. Som regel er det omvendt: dei eigne pakka til tunnelen må krysse den adapteren for å nå tenaren, og dei ser ut som vanlege UDP- eller TCP-straumar. Den indre pakken synest berre på tunneleininga. Å skilje dei to er eit spørsmål om å lese innpakkinga, ikkje om å stole på eit bytetal.

Kvar tunnelpakke kryssar framleis leidningen

Ein tunnel er eit grensesnitt, ikkje ein leidning. Klienten tek ein indre pakke, pakkar han inn og sender resultatet til adressa og porten til tenaren frå profilen. På den fysiske adapteren ser du innpakkinga; på tunneleininga ser du det som vart pakka inn.

I UDP-modus er den ytre straumen eitt adresse- og portpar i kvar retning, og difor ser ein sunn tunnel nesten keisam ut på eth0. Nettopp det eine paret er det første du bør leite etter.

Tak opp eitt grensesnitt om gongen

Tak opp berre eitt grensesnitt om gongen når du vil samanlikne tal. Pseudogrensesnittet any samlar alle einingar på ein gong, så ein vidaresend pakke synest ved inngang og utgang, og ein lokalt generert synest to gonger i to ulike former. Like pakketal med ulike bytetal er normale, fordi innpakkinga er større enn det ho ber. ARP, DHCP og IPv6-rutarmeldingar høyrer til den lokale lenkja og seier ingenting om applikasjonen din.

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

Byt ut adressa og porten med verdiane til profilen sjølv. Viss den straumen er jamn, ber tunnelen noko.

Spør kjernen kva eining han vel

Spør kjernen kva eining han ville velje, og stadfest deretter på leidningen. Ruteoppslaget er avgjerda, og opptaket er provet på at avgjerda vart følgd. Dei svarar 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

Eit delt resultat er det vanlege funnet: IPv4 går til tunnelen, og IPv6 går til den fysiske adapteren fordi profilen berre skauv inn IPv4-ruter. Det er ein ekte lekkasje, og han er usynleg i eit opptak som berre dekkjer IPv4. Filtrer på IPv6 og følg med på adresser som ikkje er tenaren og ikkje er link-local.

Køyr begge oppslaga før og etter tilkoplinga, slik at du ser kva klienten faktisk endra. Skilnaden mellom dei to køyringane er den reelle verknaden til klienten.

Når opptaket verkeleg er ein lekkasje

Av og til talar opptaket sant. Ei smalare rute som sender eitt prefiks utanom tunnelen, eit subnett klienten fekk beskjed om å utelate, eller ei brannmur-tillating som køyrer før tunnelpolitikken kan alle setje trafikk på leidningen i klartekst. Ein regel som passar ein prosessgruppe kan òg vere eit medvite unntak. Les grensesnittet og målområdet før du kallar det ein feil.

Retta opp ruta eller unntaket, ikkje brannmuren. Tak deretter opp igjen frå ei ny tilkopling og kontroller IPv4 og IPv6 kvar for seg, fordi ei retting av den eine ikkje seier noko om den andre. tcpdump-handboka dekkjer grensesnitt- og retningsveljarane som vart brukte ovanfor.