Klienci LAN ignorują VPN routera, dopóki nie włączy się routingu politycznego

Router dociera do internetu przez swój tunel, a laptop za nim nadal zgłasza adres ISP. Dodawanie reguł akceptacji nie pomaga, a ta porażka jest pouczająca: filtrowanie odpowiada, czy pakiet może przejść, a nie dokąd zmierza. Wybór interfejsu został już dokonany przez wyszukiwanie trasy, które nic nie wie o liście klientów. Napraw wyszukiwanie, a zapora przestanie być podejrzanym.

Reguła filtra nie może wybrać interfejsu

Przepływ pakietów na routerze Linux najpierw wykonuje decyzję routingu, a potem hak forward. Gdy reguła pasuje do wychodzącego urządzenia tunelu, jądro już zdecydowało, że tunel jest wyjściem. Jeśli tablica główna nadal preferuje domyślną trasę WAN, pakiet zmierza do ISP, a właśnie zapisana reguła akceptacji nigdy go nie widzi. Ten jeden fakt o kolejności wyjaśnia, dlaczego strona nowych reguł zapory niczego nie zmienia.

Poniższy przykład używa sieci LAN 192.168.8.0/24 na br-lan, urządzenia tunelu tun0 i jednego dekodera pod 192.168.8.23, który powinien korzystać z tunelu.

Przeczytaj wyszukiwanie, zanim edytujesz reguły

Poproś jądro o rozwiązanie trasy w imieniu tego klienta. Odpowiedź zawiera urządzenie wychodzące i adres źródłowy, który zostałby wybrany, i to wszystko, czego potrzeba do potwierdzenia diagnozy. Jeśli odpowiedź wskazuje urządzenie WAN, pakiet nigdy nie miał szansy dotrzeć do twojej reguły.

ip -4 route get 198.51.100.7 from 192.168.8.23

Powtórz zapytanie dla klienta, który powinien pozostać na zwykłej ścieżce. Gdy obie odpowiedzi wskazują to samo urządzenie, żadna polityka według źródła jeszcze nie działa, a poprawka należy do routingu, nie do filtrowania.

Przypisz tablicę do klientów, których chcesz objąć

Routing polityczny wstawia wyszukiwanie reguł przed tablicą główną. Zbuduj tablicę, której domyślną trasą jest tunel, a następnie powiąż ją z selektorem: interfejsem wejściowym, adresem źródłowym lub znacznikiem zapory. Priorytety decydują o kolejności, a tablica główna stoi daleko niżej na liście, na 32766, więc reguła o niskim numerze jest sprawdzana pierwsza. Selektory interfejsu obejmują każdego klienta na moście; selektory adresu obejmują jedną maszynę.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

Interfejsy firmware'u zwykle pokazują te same obiekty co strona routingu politycznego lub polityki VPN. Lista urządzeń jest tam łatwiejsza w utrzymaniu niż reguły pisane ręcznie i zwykle przeżywa aktualizacje zmieniające składnię reguł.

Wybierz selektor świadomie. Reguła interfejsu jest krótka i przyszłościowa, ale łapie też własny ruch zarządzający routera docierający na ten most. Reguła źródła jest dokładna i wymaga edycji za każdym razem, gdy zmienia się lista urządzeń. Zapisz wybór, bo będzie go potrzebować następna osoba, która zapyta, dlaczego jedno urządzenie zachowuje się inaczej.

Trzymaj cele lokalne poza tunelem

Nowa tablica zna tylko trasy, które w niej umieścisz. Brakuje prefiksu LAN, więc ruch drukarki i NAS podążyłby domyślną trasą tunelu i zniknął. Trasa throw kończy wyszukiwanie w tej tablicy i oddaje decyzję tablicy głównej.

ip -4 route add throw 192.168.8.0/24 table 200

Pomiń tę trasę, a lokalne udziały się psują, a sesja zarządzania samego routera może zniknąć, jeśli selektor jest szerszy niż zamierzano. Potem rozstrzygnij kwestię źródła: pakiety tunelu, które nadal niosą adresy LAN, potrzebują znajomości drogi powrotnej po drugiej stronie, podczas gdy masquerading na tunelu usuwa ten wymóg i usuwa też tożsamość klienta, którą widziałaby druga strona.

Reguły i trasy dodane w czasie działania znikają po restarcie lub aktualizacji firmware'u. Dodaj je do mechanizmu startowego routera, zrestartuj raz i przetestuj ponownie z klienta: jego adres publiczny, drugi klient, który powinien zostać w WAN, oraz liczniki tunelu podczas nowego połączenia.