Trasa VPN czy reguła firewalla: co gubi pakiet?

Dwie niezależne decyzje dotyczą tego samego pakietu i każda z nich może po cichu zakończyć żądanie. Wyszukiwanie trasy wybiera interfejs i następny skok, potem filtr pakietów decyduje, czy ta kombinacja jest dozwolona. Przekroczenie limitu czasu mówi, że jedno z dwojga odmówiło, a nie które. Przejdź etapy po kolei, a naprawa zwykle przestaje być domysłem.

Dwie decyzje, jeden pakiet, dwóch właścicieli

Wyszukiwanie trasy najpierw konsultuje reguły polityki, potem tablicę, na którą wskazują, i wybiera najbardziej szczegółowy prefiks pasujący do celu. Klient, który zainstalował trasę tunelu, jest właścicielem tej decyzji i nic w regule firewalla nie może jej zastąpić. Gdy wyszukiwanie wskazuje nieoczekiwane miejsce, każdy późniejszy etap pracuje na złym pakiecie.

Filtrowanie jest osobne. Na hoście Linux haki netfilter dzielą ruch według tego, dla kogo jest pakiet: wyjście opuszcza maszynę, wejście kończy się na niej, przekazywanie przez nią przechodzi. Brama, która przyjmuje klientów VPN i kieruje ich do LAN, potrzebuje ścieżki przekazywania, i to jest dokładnie ten łańcuch, który większość domyślnych konfiguracji zostawia pusty.

Wybór źródła należy do tej samej decyzji i tu kryje się większość niezgodności. Jądro wybiera adres źródłowy z interfejsu wychodzącego, chyba że trasa wskaże jakiś, więc reguła filtra napisana dla podsieci LAN nigdy nie pasuje do pakietu wychodzącego z adresem tunelu.

Przeczytaj, co wyszukiwanie naprawdę wybrało

Wydrukuj decyzję zamiast ją wnioskować. Poniższe polecenie rozwiązuje trasę, której jądro użyłoby dla tego celu, łącznie z interfejsem i źródłem, które by wybrało:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

Klienci VPN często instalują reguły polityki na priorytetach poniżej tablicy głównej, więc czysta tablica główna sama niczego nie dowodzi. Porównaj priorytety reguł z tablicami, które wybierają, i sprawdź, czy trasa tunelu przetrwa ponowne połączenie zamiast być dodawana ręcznie raz.

IPsec oparty na polityce dodaje trzeci etap dopasowania, którego routing nie obejmuje, jak opisują uwagi strongSwan o przekazywaniu dla konfiguracji tunelowych i transportowych. Polityka bezpieczeństwa wybiera ruch według prefiksu i protokołu, a trasa decyduje tylko, dokąd trafiłby niechroniony pakiet. Podsieć, która jest routowana, ale nie ma pasującego selektora, albo pozostaje niechroniona, albo jest odrzucana, zależnie od konfiguracji, i żaden z wyników nie wygląda jak problem firewalla. Wydrukuj politykę i porównaj jej selektory z prefiksami, których oczekiwałeś od tunelu.

Filtrowanie działa na haku, nie na trasie

Reguła zezwalająca na nasłuch VPN dotyczy ruchu adresowanego do samej bramy. Nie mówi nic o klientach docierających do hostów za tą bramą, ponieważ przekazywany ruch przechodzi innym łańcuchem. Czytanie zestawu reguł jako jednej płaskiej listy to zwykła przyczyna tego, że poprawnie wyglądająca reguła nigdy nie zadziała.

Liczniki szybko rozstrzygają sprawę. Reguła z zerowym licznikiem pakietów nigdy nie została osiągnięta, co wskazuje na zły łańcuch, zły interfejs lub wcześniejsze odrzucenie. Reguła z rosnącym licznikiem w polityce odrzucania to granica, której szukałeś, a pakiet jest odrzucany, a nie błędnie routowany.

Wyślij sondę ścieżką, której używa klient

Testy uruchamiane na samej bramie przechodzą przez wyjście i wejście z własnym adresem źródłowym bramy. To inna ścieżka niż przekazywane żądanie klienta, więc udany lokalny curl dowodzi mniej, niż się wydaje. Testuj z maszyny, która zawodzi, albo przypnij interfejs i źródło jawnie.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Przechwycenie na obu końcach rozdziela pozostałe przypadki. SYN, który opuszcza klienta i nigdy nie dociera, oznacza routing, szyfrowanie lub listę dostępu wyżej. SYN, który dociera i nie dostaje odpowiedzi, oznacza usługę lub jej filtr hosta, a tunel nigdy nie był problemem.

Ruch powrotny zasługuje na osobne spojrzenie. Asymetryczny routing plus filtrowanie odwrotnej ścieżki odrzucają odpowiedzi przychodzące złym interfejsem, co objawia się jako połączenie jednokierunkowe, a nie zablokowany port. Sprawdź wartość sysctl, zanim obwinisz firewall o objaw, którego nie spowodował.

Logowanie działa jako druga opinia, nie pierwszy krok. Tymczasowa instrukcja logu na łańcuchu przekazywania nazywa interfejs i adresy, które ją trafiły, i łatwo ją później usunąć. Zostaw ją na stałe, a zbudowałeś problem z objętością logów zamiast odpowiedzi.

Umieść każdą zmianę tam, gdzie przetrwa ponowne połączenie

Trasa dodana przez ip route add żyje, dopóki interfejs nie upadnie. Zapisz ją w profilu połączenia: NetworkManager akceptuje dodatkowe trasy na połączeniu, a netplan zachowuje je między uruchomieniami. Ta sama reguła dotyczy wyjątku firewalla po stronie klienta, który znika po następnym przeładowaniu.

Reguły po stronie serwera należą do pliku konfiguracji, który usługa wczytuje przy starcie, a nie do sesji interaktywnej kończącej się, gdy ją zamkniesz. Napisz regułę, przeładuj i potwierdź, że licznik się przesunął, bo przeładowanie, które odrzuciło składnię, po cichu zostawia stary zestaw reguł na miejscu.

Potem powtórz pierwotne żądanie aplikacji od początku do końca i zanotuj, która warstwa się zmieniła. Poprawka trasy, która wymagała też zmiany filtra, nadal zawiedzie, a drugą porażkę czyta się znacznie łatwiej, gdy wie się, że pierwszej już nie ma. Zanotuj datę i wersję klienta obok wyniku, ponieważ domyślne ustawienia routingu i filtrowania zmieniają się między wersjami. Trzymaj tę notatkę w zgłoszeniu, aby następna osoba zaczęła tam, gdzie skończyłeś, zamiast powtarzać dwuetapową wędrówkę.