Gdzie obserwować ruch klienta OpenVPN na bramie

Chcesz wiedzieć, do jakich celów dociera podłączony klient, więc otwierasz powłokę na serwerze VPN i wpisujesz ss. Nic użytecznego się nie pojawia, a wniosek, że tunel jest zepsuty, przychodzi nieco zbyt łatwo. Brama OpenVPN z routingiem przekazuje pakiety klienta; nie kończy ich połączeń TCP i nie posiada dla nich gniazd. Dowód mieszka gdzie indziej, a gdzie, zależy od tego, jak ruch jest obsługiwany po opuszczeniu tunelu.

Ustal, na jaki układ patrzysz

Dwa typowe kształty dają zupełnie różne dowody. Brama routująca dekapsuluje, przekazuje i być może wykonuje NAT źródła, więc połączenie klienta nadal istnieje od końca do końca bez lokalnego gniazda.

Proxy kończy ruch: przyjmuje połączenie, a następnie otwiera własne połączenie wychodzące. W takim układzie na jedno żądanie przypadają dwa połączenia, a powiązanie między nimi istnieje tylko we własnych zapisach proxy. Wiedza, który z tych dwóch wariantów wdrożyłeś, decyduje o tym, czy czytać stan przepływów jądra, czy logi aplikacji.

Większość zamieszania bierze się z domysłów. Potwierdź kształt, zanim wybierzesz narzędzie. Najpierw przeczytaj konfigurację serwera pod kątem dyrektywy proxy, bo jej obecność zmienia każdy kolejny krok. Bez niej ścieżka pakietów to routing, a stan przepływów jądra jest twoim dowodem.

Najpierw powiąż adres z sesją

Zacznij od stanu sesji serwera i ustal bieżący adres wewnętrzny klienta. Adresy z puli są recyklowane, więc adres sam w sobie jest dzierżawą, nie osobą.

Zapisz razem czas i uwierzytelnioną tożsamość, i zwróć uwagę, czy za tym klientem nie kryje się cała sieć lokalna. Jeśli zdalny koniec routuje podsieć, widoczne adresy wewnętrzne mogą być oryginalnymi hostami albo przetłumaczonymi.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Ta para odpowiada na dwa pytania naraz: który prefiks obsługuje interfejs tunelu i która sesja była aktywna w interesującym cię przedziale. Zrób to, zanim zinterpretujesz jakikolwiek wpis przepływu, bo przekonująca krotka przypięta do niewłaściwej sesji jest gorsza niż brak jakiegokolwiek dowodu.

Czytaj tablicę przepływów na bramie routującej

Gdy adres i przedział są ustalone, lista tylko do odczytu śledzonych połączeń pokazuje, co brama dla niego przekazuje. Filtruj po oryginalnym źródle, żeby nie czytać całej tablicy.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Każdy wpis zawiera dwie krotki, oryginalną i odpowiedzi, które są dwoma kierunkami jednego przepływu, a nie dwiema aplikacjami. Na ścieżce z NAT źródła oryginalna krotka zachowuje adres tunelu, a strona odpowiedzi pokazuje przetłumaczony adres bramy, i właśnie to sprawia, że wynik na pierwszy rzut oka wygląda źle.

Traktuj listę jako żywy stan, a nie historię. Krótkie przepływy mogły już wygasnąć, ruch nieśledzony nigdy się nie pojawia, a inna przestrzeń nazw sieci pokazuje inną tablicę. Dokumentacja conntrack opisuje filtry i dwukierunkowe wyjście.

Jedno ograniczone przechwycenie, aby potwierdzić odczyt

Jeśli interfejs tunelu jest widoczny tam, gdzie patrzysz, jedno ograniczone przechwycenie rozstrzyga, czy zidentyfikowane pakiety to te na przewodzie. Trzymaj filtr wąski, a limit pakietów mały.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Porównaj znaczniki czasu, protokół i porty z wpisem przepływu oraz z żądaniem, które wysłałeś jako test. Przechwycenie po NAT pokazuje tylko publiczny adres bramy, podczas gdy strona tunelu może nadal pokazywać adres klienta, i ta różnica jest informacją, a nie niespójnością.

Jeśli interfejs nic nie widzi, sprawdź ścieżkę danych, zanim uznasz, że klient jest bezczynny: ruch między klientami i niektóre ścieżki odciążenia nigdy nie przechodzą przez obserwowany punkt.

Logi proxy i granice tego, co widziałeś

Gdy proxy stoi na ścieżce, jego gniazda wychodzące są widoczne w tablicy gniazd, ale nie mapują się jeden do jednego na klientów VPN, zwłaszcza przy łączeniu w pule lub multipleksowaniu. Użyj skonfigurowanego dziennika transakcji proxy, aby skorelować tożsamość klienta, cel, znacznik czasu i dowolny zapisywany identyfikator żądania.

Sprawdź konfigurację logowania wdrożonej wersji, zamiast zakładać, że każde żądanie jest logowane domyślnie.

Na koniec bądź precyzyjny co do zakresu. Adres docelowy i port to metadane, nie URL i nie treść strony, ponieważ wewnętrzna sesja HTTPS zachowuje własną ochronę niezależnie od tunelu. Zgłoś, co zaobserwowałeś, z jakiego punktu obserwacyjnego i o jakiej porze.