Zablokuj klientom VPN wzajemne docieranie w tunelu

Dwaj klienci mogą obaj otworzyć hosta przeskoku i mimo to nie mieć żadnego interesu w otwieraniu siebie nawzajem. Dotarcie do usługi jest decyzją o przekazywaniu, podczas gdy dotarcie do partnera jest decyzją polityki, a większość stosów VPN trzyma je w osobnych obiektach. Nic, co skonfigurujesz dla pierwszego, nie wymusza drugiego. Zadanie nie polega więc na dodaniu reguły, lecz na znalezieniu obiektu, który na tym serwerze decyduje o ruchu między partnerami, zapisaniu tam blokady i udowodnieniu jej z klienta.

Trasa do współdzielonej usługi nie jest zezwoleniem między partnerami

Ogłaszanie podsieci klientów mówi partnerowi, jak położyć pakiet na przewodzie w stronę adresu innego klienta. Czy ten pakiet dotrze, rozstrzyga się później, przez to, co go przekazuje. Na bramie Linux to łańcuch FORWARD; w demonie w przestrzeni użytkownika to własna tablica sesji tunelu. Trasa odpowiada na osiągalność i pozostawia zezwolenie nietknięte.

Dlatego kontrola izolacji, która czyta tylko trasy, niczego nie dowodzi. /24 można wypchnąć do każdego klienta, podczas gdy każdy pakiet między partnerami jest odrzucany na haku przekazywania. Groźny jest przypadek odwrotny: brak jawnej reguły, zezwalające ustawienie domyślne i izolacja, która istnieje tylko dlatego, że nikt jej nie przetestował.

Zapisz wymaganie w jednej linii, zanim otworzysz terminal. Dotrzyj do bloku usług i hosta przeskoku, nie docieraj do niczego innego wewnątrz bloku klientów.

Ustal, kto naprawdę przekazuje pakiet partnera

Dwa zachowania serwera wyglądają z perspektywy klienta tak samo i wymagają różnych reguł. Albo jądro ponownie przekazuje pakiet z interfejsu tunelu, albo demon kopiuje go między sesjami i jądro nigdy go nie widzi.

WireGuard należy do pierwszej grupy: nie ma przełącznika między partnerami, więc pakiet od 10.8.0.4 do 10.8.0.5 przychodzi na wg0, trafia na hak przekazywania i jest ponownie kierowany z wg0, gdy AllowedIPs obejmuje oba adresy. OpenVPN to druga grupa, gdy w konfiguracji serwera ustawiono client-to-client, ponieważ ta dyrektywa przekazuje pakiet między sesjami w przestrzeni użytkownika. Przed napisaniem czegokolwiek sprawdź wczytaną konfigurację pod kątem tej dyrektywy. Reguły jądra, która nigdy nie widzi ruchu, nie da się odróżnić od działającej reguły, i tak wdrożenie kończy się całkowicie bez izolacji.

Czytaj efektywną konfigurację, a nie plik, który zakładasz jako wczytany, bo pakiety dystrybucji przynoszą własne włączenia. Jeśli przekazuje demon, blokada należy do jego własnych kontroli na klienta, a zapora hosta filtruje tylko ruch adresowany do hosta. Jeśli przekazuje jądro, hak przekazywania jest jedynym miejscem, które ma znaczenie.

Wdrożenia rutowane i tłumaczone wymagają jeszcze jednej kontroli: źródło, które widzi odległy klient, może nie być tym, którego oczekujesz. Wtedy reguła pasująca do podsieci klientów nie pasuje do niczego. Zanotuj adres, który przetrwa tłumaczenie, zanim napiszesz dopasowanie, i wolij dopasować parę interfejsów niż zgadywać adresy NAT.

Daj każdemu adresowi tożsamość, którą można odwołać osobno

Izolacja pada, gdy tylko dwa urządzenia dzielą jedno poświadczenie. Reguła powiązana z tą tożsamością nie może ich rozdzielić, a odwołanie zgubionego laptopa odwołuje całą grupę. Certyfikaty na urządzenie lub klucze na partnera utrzymują odwołanie lokalnie, a politykę czytelnie, bo każdy adres odpowiada dokładnie jednej osobie lub maszynie. Gdzie projekt tego nie potrafi, powiedz to w instrukcji, zamiast opisywać regułę jako drobnoziarnistą.

Przydział adresów musi zgadzać się z polityką. Zarezerwuj blok dla usług, blok dla klientów, i rozdawaj adresy klientów z puli, którą kontrolujesz, a nie z zakresu pierwszy-przychodzi-pierwszy-bierze. Jeśli serwer tłumaczy lub mostkuje, trzymaj tabelę mapowania obok konfiguracji, bo to jej potrzebuje następny czytelnik, by ponownie wyprowadzić regułę.

Umieść blokadę tam, gdzie pakiet przecina tunel

Na bramie, która przekazuje ruch WireGuard, sprawę pokrywają dwie reguły: zezwól na blok usług, potem odrzuć resztę bloku klientów. Para interfejsów waży tyle samo co adresy, bo dopasowanie tylko po celu łapie też ruch z LAN. Wczytaj je w tej kolejności, aby zezwolenie było oceniane pierwsze.

W nftables para trafia do istniejącej tabeli inet filter, najpierw zezwolenie, potem odrzucenie. Oba dopasowania przypinają parę interfejsów oraz adresy.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Po wczytaniu odczytaj łańcuch z powrotem, zamiast ufać statusowi wyjścia, i potwierdź, że obie reguły stoją w zamierzonej kolejności. Dodaj pasujące reguły ip6 dla puli IPv6, inaczej para v4 jest tylko ozdobą na tunelu dwustosowym. Jeśli serwer ma już zezwalającą politykę przekazywania, dodaj odrzucenie, zamiast zastępować cały łańcuch.

Gdy na OpenVPN włączono client-to-client, te reguły przekazywania nigdy nie pasują do ruchu między partnerami i blokada musi żyć we własnych kontrolach demona. Zachowaj reguły jądra dla ruchu adresowanego do hosta, ale nie licz ich jako kontroli izolacji.

Udowodnij blokadę z klienta, nie z serwera

Testowanie z bramy niczego nie dowodzi, bo lokalnie wytworzony ruch idzie ścieżką wyjścia i nigdy nie przecina haka przekazywania. Użyj dwóch prawdziwych klientów: jednego, który ma dotrzeć do usługi, i jednego, który ma być odrzucony. Najpierw uruchom przypadek zezwolenia, aby zepsuty tunel nie został wzięty za działającą politykę.

Z zezwolonego klienta potwierdź, że usługa odpowiada na swoim porcie. Z tego samego klienta spróbuj adresu partnera i oczekuj cichego odrzucenia, a nie odmowy:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

Odrzucony pakiet i partner offline wyglądają oba jak przekroczenie czasu, więc sprawdź liczniki, zanim cokolwiek wywnioskujesz. Potwierdź, że licznik reguły odrzucania rośnie, gdy partner jest udowodnialnie dostępny. Powtórz przez IPv6, gdzie brakująca reguła ip6 pozostawia blokadę v4 jako skuteczną. Zanotuj przyjęte i odrzucone wyniki w instrukcji z datą, bo następna migracja ponownie wyprowadzi regułę.