Ruch na eth0 nie oznacza, że tunel VPN przecieka

Widok publicznych adresów na eth0, gdy tunel jest podniesiony, wygląda jak dowód, że coś uciekło. Zwykle jest odwrotnie: pakiety samego tunelu muszą przejść przez tę kartę, aby dotrzeć do serwera, i wyglądają jak zwykłe strumienie UDP lub TCP. Wewnętrzny pakiet pojawia się tylko na urządzeniu tunelu. Odróżnienie obu to kwestia czytania otoczki, a nie zaufania do liczby bajtów.

Każdy pakiet tunelu nadal przechodzi przez przewód

Tunel to interfejs, a nie przewód. Klient bierze pakiet wewnętrzny, opakowuje go i wysyła wynik na adres i port serwera z profilu. Na karcie fizycznej widzisz opakowanie; na urządzeniu tunelu widzisz to, co zostało opakowane.

W trybie UDP strumień zewnętrzny to jedna para adresu i portu w każdym kierunku, dlatego zdrowy tunel wygląda na eth0 prawie nudno. Właśnie tej jednej pary trzeba szukać najpierw.

Przechwytuj jeden interfejs naraz

Przechwytuj tylko jeden interfejs naraz, gdy zamierzasz porównywać liczby. Pseudointefejs any zbiera wszystkie urządzenia jednocześnie, więc przekazywany pakiet pojawia się na wejściu i wyjściu, a pakiet utworzony lokalnie pojawia się dwa razy w dwóch różnych postaciach. Równe liczby pakietów przy różnych liczbach bajtów są normalne, bo otoczka jest większa niż to, co niesie. ARP, DHCP i ogłoszenia routera IPv6 należą do łącza lokalnego i nic nie mówią o twojej aplikacji.

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

Zastąp adres i port wartościami z samego profilu. Jeśli ten strumień jest stały, tunel coś niesie.

Zapytaj jądro, które urządzenie wybierze

Zapytaj jądro, które urządzenie by wybrało, a potem potwierdź na przewodzie. Wyszukanie trasy to decyzja, a przechwycenie to dowód, że decyzji posłuchano. Odpowiadają na różne pytania i potrzebujesz obu.

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

Podzielony wynik to typowe odkrycie: IPv4 idzie do tunelu, a IPv6 idzie do karty fizycznej, bo profil wepchnął tylko trasy IPv4. To prawdziwy wyciek i jest niewidoczny w przechwyceniu obejmującym tylko IPv4. Filtruj IPv6 i obserwuj adresy, które nie są serwerem i nie są link-local.

Uruchom oba wyszukania przed połączeniem i po nim, żeby zobaczyć, co klient naprawdę zmienił. Różnica między oboma uruchomieniami to rzeczywisty efekt klienta.

Gdy przechwycenie naprawdę jest wyciekiem

Czasami przechwycenie mówi prawdę. Węższa trasa, która wysyła jeden prefiks obok tunelu, podsieć, którą klientowi kazano wykluczyć, albo reguła przepuszczająca w zaporze działająca przed polityką tunelu, wszystko to może wystawić ruch na przewód jawnie. Reguła pasująca do grupy procesów też może być świadomym wyjątkiem. Przeczytaj jej interfejs i zakres docelowy, zanim nazwiesz to usterką.

Napraw trasę albo wyjątek, nie zaporę. Potem przechwyć ponownie z nowego połączenia i sprawdź IPv4 oraz IPv6 osobno, bo naprawa jednego nic nie mówi o drugim. podręcznik tcpdump opisuje selektory interfejsu i kierunku użyte powyżej.