Znaczniki nftables i routing VPN: która reguła naprawdę wygrywa

Znacznik ustawiony w nftables powinien skierować jedną klasę ruchu przez tunel, a ruch nadal wychodzi przez interfejs fizyczny. Zbiór reguł wygląda poprawnie w izolacji. Zwykle stało się to, że coś innego zapisało ten sam znacznik, albo reguła routingu pasuje do maski, której nowa wartość już nie spełnia.

Sprawdzenie 1: przeczytaj regułę, do której pasuje jądro

Zacznij od reguły polityki, a nie od zapory. Jądro przegląda reguły w kolejności priorytetów i pierwsze dopasowanie decyduje o tabeli. Odczytaj wartość fwmark i maskę z samej reguły, a następnie potwierdź, że pakiet ze znacznikiem, który ustawiłeś, naprawdę do niej pasuje. Reguła oczekująca pełnej wartości 32-bitowej nie będzie pasować do pakietu niosącego tylko jeden bit.

Następnie potwierdź, którą tabelę wybiera ta reguła i co ta tabela zawiera. Reguła wskazująca na pustą tabelę powoduje nieudane wyszukiwanie, co w wielu systemach oznacza, że pakiet spada do następnej reguły i wychodzi przez interfejs fizyczny.

Rozstrzygają to dwie komendy: lista reguł i wyszukanie trasy do celu w tej tabeli.

Sprawdzenie 2: znacznik pakietu czy znacznik połączenia

nftables może ustawić znacznik na pakiecie i znacznik we wpisie śledzenia połączeń, a to różne obiekty. Znacznik pakietu żyje przez przebieg przetwarzania pakietu, natomiast znacznik połączenia utrzymuje się dla przepływu i musi być świadomie kopiowany. Ustawienie jednego i oczekiwanie drugiego to częsta połowiczna poprawka.

Jeśli reguła routingu opiera się na znaczniku pakietu, przywrócenie znacznika połączenia później na ścieżce nic nie zmienia w tej decyzji, bo decyzja już zapadła.

Zdecyduj, który obiekt posiada sygnał routingu, a następnie ustaw go w punkcie, w którym podejmowana jest decyzja o routingu.

Sprawdzenie 3: kto jeszcze zapisuje ten znacznik

Własne narzędzia WireGuard oznaczają swoje pakiety UDP, aby zaszyfrowany transport nie był routowany z powrotem do tunelu, do którego należy. Jeśli twój zbiór reguł przypisze temu samemu polu niepowiązaną wartość, to wykluczenie znika i zewnętrzny ruch tunelu próbuje wejść w siebie. Objawem jest tunel, który się zestawia, a potem przestaje przepuszczać ruch.

Znaczniki są też używane przez inne narzędzia zapory, sieci kontenerów i routing polityki do innych celów, więc zapisywanie całego pola przez dwa podsystemy jest konfliktem, nawet gdy każdy z osobna jest poprawny.

Wypisz zapisujących, zanim dodasz kolejnego.

Sprawdzenie 4: maska decyduje, co zachowujesz

Znacznik to pole 32-bitowe, a maski to sposób, w jaki kilku właścicieli je dzieli. Ustawienie wartości z maską zachowuje bity, których nie posiadasz; ustawienie całego pola niszczy bity wszystkich innych. Czytaj maskę w każdej regule, która dotyka pola, także w tych, których nie napisałeś.

Udokumentuj przydział bitów obok zbioru reguł.

W przeciwnym razie następna osoba ponownie użyje wartości, która ma już właściciela, a konflikt tutaj wygląda jak błąd routingu, choć jest błędem adresowania. Dokumentacja nftables o metadanych pakietów opisuje same operacje na znacznikach.

Sprawdzenie 5: weryfikuj rzeczywistym przepływem, nie wyszukiwaniem

Zwykłe wyszukanie trasy nie niesie znacznika, więc może pokazać inną ścieżkę niż rzeczywisty pakiet. Wygeneruj ruch, na którym ci zależy, i obserwuj liczniki, wpis śledzenia połączeń oraz interfejs, przez który naprawdę wychodzi. Przetestuj zarówno klasę uwzględnioną, jak i wykluczoną, ponieważ zbyt szeroki znacznik psuje wykluczenie, a wygląda na udany. Jeśli klasa uwzględniona działa, a klasa wykluczona też wchodzi do tunelu, znacznik jest zbyt szeroki, a nie zbyt wąski.

Unikaj czyszczenia stanu połączeń, aby wymusić odświeżenie podczas aktywnej sesji, ponieważ nowe i istniejące przepływy mogą legalnie podążać różnymi ścieżkami.

Zapisz znacznik, maskę i tabelę w jednym miejscu, a następna zmiana stanie się możliwa do przeglądu.