Blokowanie IPv6 w celu zabezpieczenia WireGuard psuje host

Cel jest rozsądny: do usług na tej maszynie powinni docierać tylko użytkownicy tunelu. Rozwiązanie, po które sięgają ludzie, to łańcuch wejściowy IPv6 odrzucający wszystko poza WireGuardem, a to odrzuca też ruch, który utrzymuje host przyłączony do jego własnego łącza. Wykrywanie sąsiadów i komunikaty konserwacji ścieżki nie są dostępem do usług, a ich usunięcie daje maszynę nieosiągalną z powodów niezwiązanych z twoją polityką. Tunel się podnosi, usługi są poprawnie ograniczone, a nic innego na łączu nie działa.

Trzy odpowiedzialności, jeden zbiór reguł

Pierwsza odpowiedzialność to działanie sieci zewnętrznej: host musi pozostać na swoim łączu, rozwiązywać sąsiadów i znać granice ścieżki tego łącza. Druga to szyfrowany nasłuch, który przyjmuje UDP na wybranym przez ciebie adresie i porcie. Trzecia to zbiór odszyfrowanych usług, do których mają docierać użytkownicy tunelu.

To trzy różne polityki, a tylko druga i trzecia dotyczą VPN. Zbiór reguł, który traktuje je jako jedną, dziedziczy tryb awarii, w którym zaostrzenie granicy aplikacji po cichu psuje przyłączenie hosta.

Trzymaj je w osobnych łańcuchach lub przynajmniej osobnych komentarzach, żeby następna osoba widziała, która linia i dlaczego istnieje.

Co ICMPv6 robi dla hosta

IPv6 opiera się na ICMPv6 znacznie bardziej niż w przypadku echa. Zapytanie i ogłoszenie sąsiada zastępują ARP i są potrzebne do dostarczania lokalnego. Packet Too Big niesie informację o MTU ścieżki, a jej ignorowanie daje transfery, które zacinają się przy dużych pakietach. Ogłoszenia routera niosą trasę domyślną i informację o prefiksie, gdy łącze używa konfiguracji automatycznej.

RFC 4890 oddziela komunikaty, które filtr hosta musi przepuszczać, od tych, które są wyborem administracyjnym, i robi to w sekcji hosta odmiennej od reguł dla routera przekazującego między sieciami. Czytanie tylko sekcji przekazywania daje politykę wejściową zbyt surową dla hosta, którego chroni.

Praktyczna reguła to zezwolić na istotne komunikaty błędów i konfiguracji na interfejsie, który ich potrzebuje, ograniczone według typu i źródła tam, gdzie platforma na to pozwala, i wyraźnie zdecydować o reszcie.

Zastąpienie tego wszystkiego ogólnym zezwoleniem na ICMPv6 rozwiązuje problem dostępności i rezygnuje z filtrowania. Zastąpienie go ogólnym odrzucaniem rozwiązuje problem filtrowania i rezygnuje z hosta.

Najpierw wpuść tunel, potem usługę

Przyjmij transport WireGuarda na zamierzonym adresie zewnętrznym i porcie UDP, a ruch powrotny przyjmuj przez śledzenie połączeń. Następnie zezwól usługom aplikacji na przejście przez interfejs tunelu, ze źródeł, którym naprawdę dajesz uprawnienia.

Zezwolenie na zewnętrzny port UDP nie uprawnia odszyfrowanych żądań w jego wnętrzu. Właśnie ta różnica jest całym powodem, dla którego interfejs tunelu pojawia się w regułach usług.

Czytaj zbiór reguł taki, jaki jest, a nie taki, jak opisuje go plik:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

Nasłuch na adresie fizycznym to odrębne wystawienie tej samej usługi na adresie tunelu. Jeśli maszyna przekazuje też ruch do innej maszyny, to decyzja łańcucha przekazywania, a nie ta polityka wejściowa, i wymaga własnego uzasadnienia.

Testuj łącze, nie tylko tunel

Działający tunel po zmianie dowodzi mniej, niż się wydaje, bo istniejący wpis sąsiada i nawiązane połączenie mogą ukryć komunikat sterujący, który polityka teraz odrzuca.

Sprawdź przyłączenie bezpośrednio, a potem sprawdź, że wykluczona ścieżka nadal zawodzi:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

Tablica sąsiadów, która pozostaje kompletna po restarcie, jest sygnałem, że wykrywanie nadal działa. Tablica, która się opróżnia i nigdy nie wypełnia, jest sygnałem, że ją odfiltrowałeś. Trzecie polecenie sprawdza składnię zbioru reguł bez jego stosowania, co warto zrobić, póki masz jeszcze sesję.

Odzyskaj host, z którego się zablokowałeś

Zanim zmienisz reguły zapory, które niosą twoją własną sesję administracyjną, utrzymuj drugi kanał: konsolę, połączenie szeregowe lub zaplanowane wycofanie, które usuwa nowe reguły, jeśli go nie anulujesz.

Jeśli zmiana rzeczywiście cię zablokuje, odzyskiwanie odbywa się przez ten kanał, a nie przez sieć, którą właśnie usunąłeś. Przywróć poprzedni zbiór reguł z zapisanej kopii, potwierdź, że host znów jest osiągalny, i dopiero wtedy zastosuj zamierzoną politykę w mniejszych częściach.

Ostateczna polityka nie jest uniwersalna. Adresacja, routing i implementacja zapory to dane wejściowe wdrożenia, ale granica jest wszędzie taka sama: odmawiaj niechcianego dostępu aplikacji, zachowując ruch sterujący, który niesie autoryzowany tunel.