Czy ruch naprawdę przechodzi przez VPN? Jak to zweryfikować

Dwie awarie wyglądają identycznie z ikony w zasobniku: ruch, który wchodzi do tunelu, i ruch, który po cichu go omija. Klient w obu przypadkach pokazuje Connected, bo Connected oznacza tylko, że interfejs tunelu istnieje i że klient zainstalował trasy, których chciał. Czy jeden pakiet jednej aplikacji użył tych tras, to osobne pytanie, na które odpowiada się w innym miejscu stosu. Cztery pomiary rozstrzygają większość — sprawdzenie trasy, pierwszy skok, przechwycenie na karcie fizycznej i obserwacja z zewnątrz — a widok sesji na serwerze pokrywa resztę.

Zacznij od trasy, którą pójdzie pakiet

Tablica routingu jest decyzją, więc zapytaj ją o jedno miejsce docelowe zamiast czytać całą i zgadywać. W Linuksie ip route get nazywa interfejs i adres źródłowy wybrane przez jądro:

ip route get 203.0.113.10
ip route get 10.20.5.7

W Windowsie Find-NetRoute -RemoteIPAddress 203.0.113.10 jest użyteczniejszy niż route print -4 z tego samego powodu: raportuje trasę, która wygrała, a nie wszystkie istniejące trasy. Przeczytaj jednak tablicę raz ze względu na jej wiersz 0.0.0.0. Para /1 oznacza tam, że klient pełnego tunelu przepisał trasę domyślną: opcja redirect-gateway def1 OpenVPN instaluje 0.0.0.0/1 i 128.0.0.0/1 przez tunel, co wygrywa z istniejącą 0.0.0.0/0 przy najdłuższym dopasowaniu prefiksu, nie usuwając fizycznej trasy domyślnej. Dlatego dwie trasy domyślne mogą współistnieć, a wszystko i tak trafia do tunelu.

Dwa szczegóły czynią tablicę kłamliwą. Po pierwsze, patrz na dopasowany prefiks, a nie na liczbę tras domyślnych, bo metryka interfejsu lub para /1 decydują o zwycięzcy. Po drugie, istniejące połączenie zachowuje ścieżkę, z którą zostało nawiązane; po podniesieniu tunelu otwarta sesja może nadal używać starej trasy, dopóki nie zostanie zresetowana, i dlatego ponowne połączenie wydaje się naprawiać problem routingu. Działający klient — ps ax | grep openvpn — dowodzi tylko, że proces wystartował.

Prześledź jedną nazwę wewnętrzną i jedną publiczną

Sprawdzenie trasy pokazuje intencję; ścieżka pokazuje dostarczenie. Prześledź nazwę, która musi być wewnętrzna, i nazwę, która nie może, będąc połączonym, i porównaj pierwszy skok:

traceroute intranet.corp.example
traceroute 1.1.1.1

Ten sam pierwszy skok dla obu oznacza, że nazwa wewnętrzna nigdy nie weszła do tunelu, a usterka jest wyżej, zwykle nazwa rozwiązująca się na adres publiczny lub trasa, która nigdy nie została zainstalowana. Jeśli ruch wewnętrzny wychodzi przez 10.8.0.1, a publiczny przez 192.168.1.1, tunel dzielony robi dokładnie to, do czego został skonfigurowany. Ślad, który dociera do bramy VPN i potem zwraca tylko przekroczenia czasu, to zwykle problem drogi powrotnej lub zapory serwera, a nie brakująca trasa przekazywania.

Filtrowany ICMP czyni to sprawdzenie kłamliwym: gwiazdki na obu śladach wyglądają jak martwy tunel i zwykle są zaporą. Przetestuj port TCP, gdzie możesz — traceroute -T -p 443 w Linuksie — i pamiętaj, że ślad nie mówi, który resolver odpowiedział: nazwa może rozwiązać się lokalnie i mimo to być osiągalna przez tunel.

Przechwytuj na karcie fizycznej, nie na tunelu

Łącze fizyczne to jedyne miejsce, które pokazuje, co sieć naprawdę widzi. Przy podniesionym tunelu sesja do biura powinna pojawiać się jako zaszyfrowany ładunek zaadresowany do serwera VPN, a nie jako połączenie do 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Pierwszy filtr łapie rozwiązywanie nazw wychodzące lokalnie, które jest najczęstszym i najcichszym wyciekiem — strona nadal się ładuje, resolver po prostu zobaczył zapytanie. Drugi łapie zwykły ruch do adresu wewnętrznego, który powinien istnieć tylko w tunelu. W Windowsie pktmon robi to samo bez sterownika: pktmon filter add -p 53, potem pktmon start --capture --pkt-size 128, potem pktmon stop i pktmon format pktmon.etl -o capture.txt. Te flagi różnią się nieco między wersjami Windows, więc sprawdź pktmon filter add /?, zanim zaufasz składni.

Przechwyć interfejs fizyczny, aby znaleźć wycieki; przechwycenie na tunelu zawiera pakiety, o których już sądzisz, że tam są, a na serwerze zawiera nieczytelne pakiety zewnętrzne, których źródłem jest brama. Liczniki bajtów na dowolnym interfejsie opisują pakiety, nie programy; przypisanie ruchu do procesu wymaga monitora, który mapuje gniazda na procesy.

Zapytaj zewnętrzną usługę, a potem zapytaj ponownie dla każdej aplikacji

Jedynym sprawdzeniem, które dowodzi wyjścia, jest odpowiedź z zewnątrz: usługa, która zwraca widziany adres źródłowy. Uruchom ją z powłoki, gdzie możesz wybrać interfejs, i uruchom dwa razy:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Różne odpowiedzi dają dowód obu ścieżek i sposób przetestowania konkretnej aplikacji: przypisz ją do interfejsu albo uruchom w przestrzeni nazw sieci z jedną trasą i zobacz, który adres zapisze drugi koniec. Identyczne odpowiedzi to ciekawa usterka: albo przypisanie nie zadziałało, albo coś między hostem a drugim końcem przepisuje adres źródłowy, zanim dotrze. W Windowsie curl --interface chce adresu karty, a nie jej nazwy.

Przeglądarka raportująca adres VPN dowodzi przeglądarki. Klient poczty, menedżer pakietów, agent kopii zapasowych lub drugi profil przeglądarki mogą każde iść inną ścieżką, zwłaszcza gdy ustawienie proxy lub trasa tunelu dzielonego obejmuje jedno z nich. Zmiana adresu sama w sobie nie jest dowodem wycieku: równoważnik obciążenia może odpowiedzieć inaczej zależnie od widzianego wyjścia, więc porównuj zapisany adres źródłowy, a nie stronę.

Użyj widoku serwera, aby potwierdzić peera

Serwer odpowiada na inne pytanie: czy peer jest połączony, ile przeniósł i czy sesja została zrestartowana. Peer aktywny na serwerze, gdy liczniki klienta ledwie drgną, oznacza, że ruch aplikacji nie wchodzi do tunelu, cokolwiek mówiła tablica klienta. Peer przenoszący dużo danych dla użytkownika, który zgłasza, że nic nie działa, to inne dochodzenie.

Są tu dwie pułapki. Tunel maskaradowany sprawia, że każdy przepływ wygląda jak przychodzący z bramy, więc logi i rozliczenia na klienta zlewają się w jeden adres. A klient jest traktowany jak host lokalny, więc pytanie, czy ktoś kopiuje pliki przez VPN, rozstrzyga ruch udostępniania plików na serwerze lub audyt hosta na serwerze — obserwacja tunelu daje punkty końcowe i wolumen, a nie nazwy plików.

Odróżnij decyzję projektową od wycieku

Nie wszystko poza tunelem to wyciek. Ruch łącza lokalnego i rozgłoszeniowy pozostaje lokalny z założenia, drukarka znaleziona przez multicast nadal ogłasza się w sieci LAN, a DHCP musi wyjść lokalnie. Aplikacja przypisana do konkretnego interfejsu celowo omija tablicę routingu, a zmienia to tylko reguła zapory, przestrzeń nazw lub trasa polityki.

IPv6 zasługuje na własny wiersz listy kontrolnej. Tunel przenoszący tylko IPv4 zostawia hostowi dwustosowemu drugą użyteczną ścieżkę, a cel dwustosowy ją preferuje — także DNS, jeśli resolver jest osiągalny przez IPv6. Wyłącz IPv6 na karcie lub potwierdź, że tunel go przenosi, zanim uznasz wynik IPv4 za kompletny.

Gdy sprawdzenia się nie zgadzają, niezgodność zwykle nazywa usterkę:

Działająca kolejność: zapisz tablicę routingu przed i po połączeniu, prześledź jedną nazwę wewnętrzną i jedną publiczną, przechwyć DNS na karcie fizycznej, zwróć adres wyjścia z powłoki dla konkretnej aplikacji, a potem odczytaj serwer pod kątem wolumenu. Jeśli pierwsze cztery się zgadzają, tunel przenosi to, co myślisz, a pozostały problem jest wyżej. Jeśli dwa się nie zgadzają, niezgodna para jest usterką, nie ikona.