Ograniczyć bramę OpenVPN do jednej sieci LAN regułami UFW

Zdecyduj o pozwoleniu, zanim otworzysz plik zapory ogniowej: uwierzytelnieni klienci mogą otwierać połączenia do jednej określonej podsieci, a brama musi odrzucać każdą inną drogę tranzytu, nawet gdy klient zainstaluje dodatkowe trasy. To zdanie jest projektem, a każda reguła poniżej istnieje, aby je wyegzekwować. Coś szerszego, na przykład cała prywatna przestrzeń adresowa, wyjście do internetu przez tunel albo ruch między równorzędnymi węzłami, to inny projekt, który wymaga własnej decyzji. Reguły są też celowo nudne, bo sprytna zapora ogniowa to taka, której nikt później nie może zrecenzować.

Najpierw zapisz topologię i pozwolenie

Przykład używa serwera Community OpenVPN z urządzeniem TUN w przestrzeni użytkownika o nazwie tun0, puli klientów 10.77.0.0/24, i jednej podłączonej podsieci 192.168.60.0/24 na lan0. Przekazywanie IPv4 już działa, a sieć LAN ma już trasę powrotną do puli, więc nic tutaj nie zależy od tłumaczenia między nimi.

Zaporą ogniową na tym hoście zarządza UFW i żaden zestaw reguł kontenera ani osobna tablica nftables nie może zainstalować wcześniejszej ścieżki akceptacji. Skrót odciążenia przepływu, który omija filtr, uczyniłby łańcuchy straży dekoracją, więc potwierdź, że żaden nie jest aktywny. Zostaw własne przekazywanie client-to-client OpenVPN wyłączone, ponieważ ruchu między równorzędnymi węzłami, który nigdy nie przechodzi przez filtr systemu operacyjnego, nie da się nim ograniczyć. Zewnętrzny nasłuch i reguły administracyjne pozostają bez zmian, bo ta zmiana reguluje odszyfrowany ruch tunelu, a nie zastępuje zapory ogniowej.

Umieść straże przed wczesnymi akceptacjami UFW

Pozwolenie na trasę, po którym następuje odmowa, nie wystarcza do ścisłej granicy. Standardowe reguły before akceptują ustalony ruch i wybrane ICMP, zanim zostanie wzięta pod uwagę jakakolwiek reguła użytkownika, więc przepływ dozwolony w zeszłym tygodniu może pozostać poza nowym ograniczeniem celu tylko dlatego, że nadal ma stan. Zrób kopię plików UFW i trzymaj otwartą konsolę poza pasmem przed edycją.

W sekcji *filter pliku /etc/ufw/before.rules zadeklaruj dwa łańcuchy obok istniejących deklaracji i przed każdą linią reguły.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Zaraz po deklaracjach, i przed pozwoleniami na wejście i przekazywanie, wskocz do nich i określ, co przepuszczają.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Zachowaj resztę sekcji i jej linię COMMIT. Wklejenie drugiej tablicy filtra lub usunięcie niepowiązanych reguł to sposób, w jaki zmiana zapory staje się awarią, a plik jest o jedno uruchomienie od bycia jedyną kopią, która ma znaczenie.

Przeczytaj, co każda straż przepuszcza i odrzuca

Pierwszy łańcuch kontynuuje przetwarzanie tylko wtedy, gdy źródło jest w puli, cel jest tą jedną podsiecią, interfejs wyjścia to sieć LAN, a pakiet porusza się w pierwotnym kierunku swojego przepływu. Wszystko inne, co przychodzi z tunelu, jest odrzucane, w tym źródło spoza puli i dowolny cel poza dozwoloną podsiecią.

Pakiet między równorzędnymi węzłami wchodzi i wychodzi przez tun0, więc nie przechodzi testu interfejsu LAN nawet zanim dotrze do sprawdzenia celu. Nowe połączenia z sieci LAN do klientów także nie przechodzą testu kierunku odpowiedzi, co domyślnie zamyka odwrotną ścieżkę wywołania zwrotnego.

Cel RETURN utrzymuje zwykłą politykę UFW w grze. Te łańcuchy filtrują, a pozwolenie na trasę dodane później nadal decyduje, czy pakiet, który przetrwał, zostanie przyjęty. Właśnie to rozdzielenie pozwala później zmienić dozwoloną podsieć w jednym miejscu. Gdyby straże przyjmowały pakiety wprost, każdą przyszłą regułę trzeba by dodawać dwa razy.

Zezwól na podsieć i zamknij boczne drzwi

Najpierw podejrzyj pozwolenie na trasę, a potem zdejmij flagę podglądu, aby je zastosować: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Następnie przejrzyj kolejność reguł użytkownika, bo wcześniejsza odmowa nadal wygrywa z późniejszym pozwoleniem. Pozwolenie na całą podsieć to też zły kształt, gdy ma być osiągalny tylko port HTTPS jednego hosta.

Zwróć uwagę, co robi odrzucanie wejścia: klienci tunelu nie osiągną żadnej usługi na samej bramie, w tym nasłuchu DNS związanego z jej adresem w sieci LAN. Hostowanie tam DNS wymaga celowego wyjątku przed odrzucaniem i zrewidowanej umowy pozwolenia. Jeśli UFW zarządza IPv6, dodaj też odpowiednie odrzucania dla tun0 w pliku before6.rules, bo lista celów IPv4 nic nie mówi o pakietach IPv6.

Sprawdź wczytaną politykę, a nie podgląd

Podejrzyj przeładowanie, zastosuj je w oknie serwisowym i odczytaj działający zestaw reguł.

sudo ufw --dry-run reload
sudo ufw show raw

Potwierdź, że straże tunelu pojawiają się przed domyślnymi pozwoleniami na stan i ICMP. Zwykłe ufw status nie pokazuje ręcznie edytowanych reguł before, dlatego operatorzy sądzą, że brakuje reguły, choć jest ona faktycznie wczytana. Czytaj surową listę od góry do dołu zamiast szukać fragmentu. Jeśli straże pojawiają się po pozwoleniu na stan, granica nie robi tego, co sugeruje plik.

Potem testuj zachowanie, a nie tekst. Otwórz nowe połączenie do dozwolonego hosta i obserwuj odpowiedź, skieruj nieszkodliwe żądanie do celu spoza podsieci i potwierdź, że ginie, spróbuj połączenia między równorzędnymi węzłami, spróbuj usługi lokalnej na bramie i spróbuj niechcianego połączenia z sieci LAN do klienta. Uwzględnij jeden przepływ poza zakresem, który istniał przed zmianą, i wyczyść tylko ten przepływ, zamiast opróżniać całą tablicę śledzenia maszyny.

Zapisz ograniczenia obok reguł: to ogranicza tranzyt i nic więcej. Nie powstrzymuje klienta przed korzystaniem z własnego połączenia internetowego, nie powstrzymuje dozwolonego hosta w sieci LAN przed przekazywaniem ruchu dalej i nie zastępuje uwierzytelniania wewnątrz dozwolonych usług.