Zablokuj jeden zakres docelowy dla każdej puli klientów VPN

Jedna reguła może trzymać dozwoloną pulę VPN z dala od zakresu docelowego, nie zakłócając niczego innego, co robi brama. Sama reguła jest krótka; o tym, czy zadziała, decydują hook, w którym żyje, i jej pozycja w łańcuchu. Pomylenie tych dwóch rzeczy daje zaporę, która wygląda poprawnie i zachowuje się niespójnie. Zacznij od tego, co robi pakiet, gdy reguła go widzi.

Co reguła faktycznie dopasowuje

Reguła dopasowuje trzy rzeczy naraz: interfejs wejściowy, prefiks źródłowy i prefiks docelowy. Wszystkie trzy muszą być prawdziwe, zanim zadziała drop, i to utrzymuje ją wąską. Czytanie jej jako jednego wyrażenia jest łatwiejsze niż jako trzech osobnych polityk.

Dopasowanie interfejsu odróżnia przekazywany ruch klientów od własnych połączeń bramy. Bez niego reguła wymieniająca tylko pulę źródłową dotknęłaby także pakietów, które sama brama generuje z tego adresu, jeśli kiedykolwiek to robi. Prefiks źródłowy ogranicza politykę do dozwolonych klientów, a prefiks docelowy do jednego zakresu. Czytaj regułę jako przecięcie, a nie listę.

Zapisz trzy wartości, zanim cokolwiek zmienisz: nazwę interfejsu tunelu, pulę, którą serwer przydziela, i prefiks, który zamierzasz odrzucić. Literówka w którejkolwiek z nich daje regułę, która parsuje się czysto i niczego nie chroni. Trzymaj te trzy wartości w zapisie zmian obok reguły.

Hook decyduje, kogo dotyczy reguła

Łańcuch netfilter jest podpięty do hooka, a hook decyduje, które pakiety łańcuch w ogóle widzi. Hook forward widzi ruch kierowany przez bramę, a to właśnie ruch od klienta do celu. Wszystko inne w łańcuchu jest skierowane do innego odbiorcy.

Hook input widzi ruch adresowany do samej bramy, więc reguła umieszczona tam reguluje dostęp do jej własnych usług, a nie tranzyt. Hook output widzi ruch, który brama sama tworzy, a to przeciwieństwo tego, czego potrzebuje polityka puli klientów. Nazwy łańcuchów to dowolne etykiety wybrane przez autora zestawu reguł, więc nie wnioskuj hooka z nazwy. Sprawdź, gdzie łańcuch jest podpięty, zanim założysz, co może dopasować.

Odczytanie podpięcia to jednolinijkowa kontrola, która nie pozwala regule trafić do łańcucha, który nigdy nie widzi pakietu.

Umieść regułę przed szerokim accept

Reguły są oceniane po kolei i pierwszy werdykt wygrywa. Szeroki accept wcześniej w łańcuchu kończy ocenę dla pakietów, które dopasowuje, więc drop dodany później nigdy się dla nich nie wykona. Ta zasada kolejności jest całym powodem, dla którego poprawnie wyglądająca reguła może nie mieć żadnego efektu.

Wstaw regułę przed accept, zamiast dopisywać ją na końcu. Jeśli łańcuch zawiera już ogólny accept dla interfejsu tunelu, nowa reguła musi go poprzedzać, inaczej jest tylko ozdobą. Sprawdź wynikową kolejność, a nie plik, który edytowałeś, bo zestaw reguł złożony z kilku plików może nie odpowiadać żadnemu z nich. Następnie potwierdź pakietem testowym z puli.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

Trzecie polecenie parsuje plik bez stosowania go, co wyłapuje błędy składni, zanim staną się awarią. Zastosuj je z planem wycofania, bo błędna reguła w łańcuchu forward może przeciąć tunel, przez który pracujesz.

Istniejące przepływy nie przejmują się twoją nową regułą

Wpis conntrack utworzony przed powstaniem reguły nadal pasuje do wcześniejszego accept. Dlatego nowy drop czasem wygląda, jakby działał dla nowych połączeń, a dla testowanego nie robi nic.

Przeczytaj dopasowanie stanu na początku łańcucha. Jeśli przyjmuje ruch established i related przed twoją regułą, każdy już trwający przepływ płynie dalej, aż się zamknie. Zwykle to zachowanie, którego chcesz dla reguły awaryjnej, i jest mylące, gdy oczekujesz natychmiastowego odcięcia. Zdecyduj, jaki efekt chcesz, przed wdrożeniem. Test, który używa ponownie otwartego połączenia, opowie ci złą historię.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

Pierwsze polecenie pokazuje, czy przepływ istnieje, a drugie, czy wczesna reguła stanu nadal go przyjmuje. Oba są tylko do odczytu i bezpieczne do uruchomienia podczas incydentu.

Czym ta reguła nie jest

Reguła nie jest czarną listą domen, polityką IPv6 ani ograniczeniem na pojedyncze konto aplikacji.

Każde z nich wymaga własnego mechanizmu. Blokada domeny musi rozwiązywać nazwy, czego filtr pakietów nie robi. Ruch IPv6 wymaga własnego dopasowania, bo wyrażenie ip nie mówi nic o pakietach ip6. Ograniczenie na poziomie aplikacji należy do usługi lub uwierzytelnionego proxy, a nie do dopasowania prefiksu. Właśnie rozdzielenie tych wymagań nie pozwala, by od jednej wąskiej reguły żądano czterech zadań.

Kontrakt, który daje ta reguła, jest precyzyjny: ruch z dozwolonej puli do jednego prefiksu docelowego jest odrzucany, a niepowiązany ruch bramy zachowuje swoją dotychczasową politykę. Zapisz to zdanie obok reguły, a następna osoba będzie wiedziała, po co była.