Grupy peerów WireGuard na hubie: własność źródła i polityka

Hub uruchamiający WireGuard może utrzymywać grupy peerów osobno bez osobnego interfejsu ani tablicy routingu dla każdej grupy. Tę pracę wykonują dwa mechanizmy, a mieszanie ich to zwykła przyczyna tego, że polityka wygląda poprawnie i nic nie robi. Jedna warstwa decyduje, kto może rościć sobie adres źródłowy. Druga decyduje, dokąd temu pakietowi wolno iść.

Dwa zadania, trzymane osobno

Warstwa tunelu odpowiada na wąskie pytanie: czy klucz tego peera autoryzował ten wewnętrzny adres źródłowy. Warstwa przekazywania odpowiada na szersze: czy ten pakiet może wyjść w stronę tego celu. Żadna nie odpowiada na pytanie drugiej i żadna sama w sobie nie jest pełną polityką dostępu.

Ten podział sprawia, że peer może być uwierzytelniony, poprawnie zaadresowany i mimo to nie móc dotrzeć do hosta, do którego nie powinien docierać. Wyjaśnia też odwrotność: reguła firewalla, która pozwala na wszystko, niczego nie dowodzi w kwestii tego, kto może rościć sobie który adres.

Projektuj obie warstwy razem, a potem przetestuj obie. Konfiguracja poprawna w jednej warstwie i nieprzetestowana w drugiej zawodzi otwarcie lub zamknięcie w zależności od wartości domyślnej.

Daj każdemu peerowi tylko jego własny adres

Peery z wieloma hostami kuszą, by po stronie serwera przyznać cały zakres grupy. To uprawnienie jest roszczeniem do adresu źródłowego, więc przejęty lub błędnie skonfigurowany klient może przedstawić dowolny adres z zakresu, a tunel go zaakceptuje. Przydziel /32 na peera dla jego własnego adresu wewnętrznego. Zakresy grup ustawiaj tylko na klientach, gdzie opisują do których celów ten klient może dotrzeć, a nie z których źródeł może korzystać.

Firewall dopasowuje wtedy źródło, któremu może zaufać. Reguła napisana dla zakresu grupy nadal jest użytecznym grupowaniem i staje się znacząca dopiero wtedy, gdy żaden pojedynczy peer nie może rościć sobie adresu należącego do innego członka.

Napisz politykę przekazywania, która rozdziela grupy

Ciekawy ruch tutaj wchodzi i wychodzi przez ten sam interfejs tunelu, więc przechodzi ścieżką przekazywania, a nie ścieżką wejściową hosta. Reguły należą do istniejącego łańcucha przekazywania tego menedżera firewalla, który posiada hosta, i są fragmentami, a nie pełnym zestawem reguł.

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

Pierwsze dwie reguły pozwalają na ruch w obrębie każdej grupy. Ostatnia blokuje wszystko inne, co przechodzi przez ten interfejs, i to tworzy izolację między grupami. Dodaj jawne reguły dla drugiej rodziny adresów, jeśli ich potrzebujesz, bo drop napisany dla IPv4 nie upoważnia ani nie opisuje zachowania IPv6.

Kolejność decyduje, czy polityka działa

Kolejność reguł ma większe znaczenie niż sam fragment. Ogólna reguła akceptująca nawiązane połączenia, umieszczona przed tymi wpisami, pozwala staremu przepływowi między grupami trwać, więc izolacja dotyczy tylko nowych połączeń. Zdecyduj, który z tych dwóch wyników chcesz, zanim przeładujesz.

Werdykt akceptacji też nie zawsze jest ostateczny między łańcuchami przy tym samym hooku. Jeśli inny łańcuch bazowy uruchomi się później, skuteczną polityką jest kombinacja, więc sprawdzaj liczniki, a nie plik, który edytowałeś. Liczniki są najtańszym dostępnym dowodem. Reguła bez licznika pakietów nie pasuje, a reguła, która pasuje, podczas gdy późniejszy łańcuch akceptuje, mówi ci, że drop jest w złym miejscu.

Testuj macierz, a nie liczbę plików

Zbuduj małą macierz oczekiwanych wyników i sprawdź każdą komórkę. Grupa A do grupy A powinna działać, grupa B do grupy B powinna działać, a A do B nie powinna, w obu kierunkach i dla obu rodzin adresów, jeśli je obsługujesz.

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

Pierwsze dwa pokazują, co jest skonfigurowane. Ping od członka złej grupy pokazuje, co dzieje się naprawdę. Lista conntrack pokazuje, czy starszy przepływ jest nadal akceptowany, i właśnie tak zmiana izolacji po cichu nie wchodzi w życie.

Usługi hosta na hubie i dostęp do sieci LAN za nim to osobne ścieżki z osobną polityką. Zanotuj, które z nich obejmuje macierz, bo test sprawdzający tylko ruch między peerami nie mówi nic o żadnej z nich.