Trafik på eth0 betyder inte att VPN-tunneln läcker

Att se publika adresser på eth0 medan tunneln är uppe känns som bevis för att något har sluppit ut. Oftast är det tvärtom: tunnelns egna paket måste korsa det nätkortet för att nå servern, och de ser ut som vanliga UDP- eller TCP-strömmar. Det inre paketet syns bara på tunnelenheten. Att skilja de två är en fråga om att läsa höljet, inte om att lita på ett bytetantal.

Varje tunnelpaket korsar fortfarande ledningen

En tunnel är ett gränssnitt, inte en ledning. Klienten tar ett inre paket, packar in det och skickar resultatet till serverns adress och port från profilen. På det fysiska nätkortet ser du höljet; på tunnelenheten ser du det som packades in.

I UDP-läge är det yttre flödet ett enda adress- och portpar i varje riktning, och därför ser en frisk tunnel nästan tråkig ut på eth0. Just det enda paret är det första att leta efter.

Fånga ett gränssnitt åt gången

Fånga bara ett gränssnitt åt gången när du tänker jämföra antal. Psevdogränssnittet any samlar varje enhet på en gång, så ett vidarebefordrat paket syns vid ingång och utgång och ett lokalt genererat syns två gånger i två olika former. Lika paketantal med olika byteantal är normalt, eftersom höljet är större än det det bär. ARP, DHCP och IPv6-routerannonser hör till den lokala länken och säger ingenting om din applikation.

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

Byt ut adressen och porten mot profilens egna värden. Om det flödet är jämnt bär tunneln något.

Fråga kärnan vilken enhet den väljer

Fråga kärnan vilken enhet den skulle välja och bekräfta sedan på ledningen. Routsökningen är beslutet, och fångsten är beviset för att beslutet följdes. De svarar på olika frågor och du vill ha båda.

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

Ett delat resultat är det vanliga fyndet: IPv4 går till tunneln och IPv6 går till det fysiska nätkortet eftersom profilen bara sköt in IPv4-rutter. Det är en riktig läcka, och den är osynlig i en fångst med bara IPv4. Filtrera på IPv6 och håll utkik efter adresser som inte är servern och inte är link-local.

Kör båda sökningarna före och efter anslutningen, så att du ser vad klienten faktiskt ändrade. Skillnaden mellan de två körningarna är klientens verkliga effekt.

När fångsten verkligen är en läcka

Ibland talar fångsten sanning. En snävare rutt som skickar ett prefix runt tunneln, ett subnät som klienten fick order att utesluta, eller ett brandväggstillstånd som körs före tunnelpolicyn kan alla sätta trafik på ledningen i klartext. En regel som matchar en processgrupp kan också vara ett medvetet undantag. Läs dess gränssnitt och destinationsomfång innan du kallar det ett fel.

Rätta rutten eller undantaget, inte brandväggen. Fånga sedan igen från en ny anslutning och kontrollera IPv4 och IPv6 var för sig, eftersom en rättning av det ena inte säger något om det andra. tcpdump-handboken beskriver de gränssnitts- och riktningsväljare som användes ovan.