Kieruj poza VPN tylko jedną lokalną usługę webową według portu

Jedna usługa hosta musi odpowiadać internetowi przez fizyczne łącze nadrzędne, podczas gdy wszystko inne na maszynie nadal korzysta z tunelu. Trzy warunki decydują, czy routing oparty na politykach udźwignie to obciążenie, a każdy z nich jest tani do sprawdzenia przed napisaniem reguły. Usługa musi kończyć się na tym hoście, a nie za DNAT lub przekierowanym portem, własne reguły VPN muszą dopuszczać wyjątek, a ty musisz dopasowywać odpowiedź, a nie żądanie. Jeśli zawiedzie którykolwiek z trzech, poniższe polecenia wczytają się czysto, ale nie zrobią nic użytecznego.

Sprawdź trzy warunki, zanim napiszesz regułę

Kontener publikujący port przez DNAT albo serwer za przekierowaniem portu tworzy pakiety, które nie powstają na tym hoście. Te pakiety są przekazywane dalej, więc reguła oparta na lokalnym wejściu hosta nigdy ich nie widzi i ruch nadal korzysta z trasy domyślnej. Potwierdź, gdzie usługa faktycznie działa, zanim przejdziesz dalej, bo to warunek, w którym ludzie mylą się najczęściej.

Drugi warunek to polityka, a nie mechanika. Każda trasa omijająca tunel jest wyjątkiem od celu tunelu, a na zarządzanym hoście ta decyzja należy do właściciela polityki, nie do osoby debugującej limit czasu.

Dopasuj odpowiedź, a nie port docelowy klienta

Odpowiedź serwera nasłuchującego na TCP 443 opuszcza host z portem źródłowym 443. Przeglądarka na tym samym hoście łącząca się ze zdalną witryną HTTPS wysyła efemeryczny port źródłowy i port docelowy 443. Oba są ruchem portu 443 i tylko jeden z nich powinien korzystać z tabeli WAN, dlatego dopasowanie portu docelowego złapałoby niewłaściwą połowę.

Kierunek odpowiedzi jest tym, co możesz rozróżnić. Dopasuj port źródłowy, ogranicz regułę do pakietów tworzonych lokalnie, a reguła obejmie własne odpowiedzi usługi bez dotykania żądań przeglądarki.

Zbuduj pełną tabelę powrotną, zanim reguła na nią wskaże

Pusta tabela oznacza brak trasy, co wygląda na zepsutą usługę, a nie zepsutą politykę. Najpierw ją wypełnij numerem tabeli i priorytetem, których nic innego na hoście nie zajmuje:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Odczytaj numery z działającego hosta, zamiast je kopiować. ip -4 rule show mówi, które priorytety są zajęte, a dodanie reguły do już istniejącego priorytetu po cichu zmienia kolejność dwóch reguł, które osobno wyglądają dobrze.

Prawdziwą pracę wykonują tu dwa selektory. iif lo to sposób, w jaki jądro zgłasza pakiety wygenerowane przez sam host, więc reguła nie może przypadkiem złapać przekazywanego ruchu przychodzącego z zewnątrz. ipproto tcp sport 443 zawęża to do jednego transportu i jednego portu, co jest tak ciasne, jak pozwala wymóg. Usuń selektor protokołu, a reguła złapie też UDP 443, czyli inną usługę o innym zachowaniu.

Trzymaj prywatne odpowiedzi wewnątrz tunelu

Jeśli ten sam nasłuchujący odpowiada też klientom po stronie prywatnej, domyślna trasa WAN łapiąca wszystko w tabeli 100 spróbuje odesłać te odpowiedzi przez łącze nadrzędne. Dodaj prefiksy prywatne, które nie mogą podążać za domyślną trasą WAN, albo pozwól im przejść do następnej reguły polityki:

ip -4 route add table 100 throw 10.90.0.0/24

Trasa throw kończy wyszukiwanie w tej tabeli i zwraca pakiet do listy reguł, więc następna polityka VPN dostaje swoją szansę. Sama nie kieruje niczego do tunelu, a jeśli żadna późniejsza reguła nie ma pasującej trasy, pakiet nadal zawodzi; zweryfikuj następną politykę, zamiast zakładać, że throw to rozwiązanie.

Filtrowanie trasy odwrotnej i reguły zapory hosta nadal dotyczą przychodzącego żądania. Spójrz na ich rzeczywiste rozstrzygnięcia, zanim poluzujesz walidację, bo wyjątek routingu nie sprawia, że rp_filter zaakceptuje trasę powrotną, którą uznaje za niemożliwą.

Przetestuj TCP, potem QUIC, potem restart

Otwórz jedno połączenie z autoryzowanego klienta zewnętrznego i jedno ze strony prywatnej, a następnie sprawdź wyszukiwanie odpowiedzi z rzeczywistymi adresami i portami. Jeśli odpowiedź zewnętrzna zajmuje tabelę 100, a prywatna nie, polityka robi to, o co prosiłeś.

HTTP/3 jest dostarczany przez UDP i nie zostanie dopasowany przez regułę TCP, więc nasłuchujący QUIC potrzebuje własnego selektora, inaczej nadal będzie korzystał z tunelu, podczas gdy HTTPS działa. Zachowaj reguły, na których się zatrzymasz, w komponencie, który posiada interfejs, i potwierdź je po ponownym połączeniu lub odnowieniu DHCP. Gdy konkurencyjny menedżer usunie trasę czasu działania po restarcie, to problem własności do naprawy u źródła, a nie powód, by dokładać szersze reguły NAT.