Pusta tabela VPN sama z siebie niczego nie blokuje

Reguła polityki wysyła oznaczone pakiety do dedykowanej tabeli, a zwykłe oczekiwanie jest takie, że utrata trasy VPN je zablokuje. Mechanizm robi coś innego. Gdy tabela nie zawiera pasującej trasy, wyszukiwanie przechodzi do następnej reguły zamiast się zatrzymać, a tabela main nadal zawiera zwykłą trasę domyślną dla uplinku. Wynikiem jest konfiguracja, która wygląda na fail-closed, a zachowuje się jak fail-open.

Nic nie jest zepsute; tak właśnie określono routing oparty na politykach.

Wyszukiwanie trwa dalej, gdy tabela nic nie zawiera

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Weź ten zestaw reguł: oznaczone wyszukiwanie trafia do tabeli 42, a późniejsza reguła wysyła ten sam znacznik do tabeli o nazwie default. Dopóki tabela 42 zawiera użyteczną trasę domyślną, pierwsze wyszukiwanie dostarcza ścieżkę. Gdy ta trasa znika i nic innego w tabeli 42 nie pasuje, wyszukiwanie nie staje się odrzuceniem; przetwarzanie przechodzi do następnej reguły, a gdy i ona niczego nie znajdzie, dociera do tabeli main. Nic w tej sekwencji nie informuje, która reguła dała ostateczną odpowiedź, więc działające połączenie wygląda jak działająca polityka.

Tabela 253, zwykle nazywana default, jest zwykłą tabelą routingu i zazwyczaj jest pusta. Jej nazwa nie jest poleceniem odrzucania pakietów i nie jest tym samym co domyślna trasa docelowa wewnątrz tabeli.

Akcje terminalne kończą wyszukiwanie

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Reguła terminalna może następować po wyszukiwaniu VPN zamiast wyszukiwania w pustej tabeli. Z tym samym znacznikiem akcja prohibit umieszczona po regule tabeli 42 kończy wyszukiwanie, gdy ta tabela nic nie daje, i zwraca odmowę administracyjną zamiast dać tabeli main kolejną szansę. Unreachable i blackhole też są terminalne, z innym zachowaniem błędu dla nadawcy.

Trasa typu throw jest inna: w tej tabeli zachowuje się tak, jakby nic nie pasowało, więc późniejsze reguły nadal mają swoją kolej. To czyni throw użytecznym do świadomego wycofania i błędnym jako ostateczna blokada.

Sprawdź z rzeczywistym znacznikiem i interfejsem

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Przeanalizuj rzeczywiste reguły i tabelę, a nie diagram, a następnie odpytaj przepływ z kontekstem źródła, znacznika i wejścia, który naprawdę ma. Wyszukiwanie tylko do odczytu skierowane do celu, któremu podano adres źródłowy, interfejs i znacznik, raportuje trasę, którą wybrałby kernel, bez wysyłania pakietu. Podanie znacznika w zapytaniu nie dowodzi, że firewall oznacza rzeczywisty ruch; to osobna kontrola reguł oznaczania. Potwierdź wartość licznikiem lub logiem, zanim wyciągniesz wnioski z zapytania.

Lokalnie generowane żądania wymagają własnego kontekstu, ponieważ ich ścieżka oznaczania często różni się od ścieżki ruchu przekazywanego. Sprawdź je interfejsem wyjściowym, którego aplikacja naprawdę by użyła.

Dwa stany awarii, a nie jeden

Jeden stan awarii to zniknięcie trasy VPN i spadanie ruchu na uplink. Martwy tunel, którego trasa pozostaje zainstalowana, to inny: pakiety pozostają kierowane w bezużyteczną ścieżkę zamiast spadać, a objawem jest cicha utrata, a nie widoczne połączenie bezpośrednie. Przetestuj oba, a także zachowanie przy starcie, ponownym połączeniu i zatrzymaniu usługi.

Taka reguła pomaga tylko dopóki istnieje i dopóki pakiety nadal noszą znacznik, który ją wybiera. Skrypt wyłączający, który usuwa regułę, albo ścieżka, która zdejmuje znacznik, przywraca otwarte zachowanie. Te przejścia warto przećwiczyć.

Stosuj politykę do IPv6 osobno i utrzymuj zatwierdzone wyjątki punktów końcowych jako jawne, a nie domniemane.