AllowedIPs to lista routingu, a nie reguła firewalla

Wybiera peera dla ruchu wychodzącego i weryfikuje źródła przychodzące. To nie lista dostępu, a wyłączenie zarządzania trasami nie naprawia podzielonego tunelu.

Większość ludzi czyta AllowedIPs jako listę uprawnień, zbiór adresów, które mogą łączyć się z peerem, mniej więcej jak reguła firewalla napisana dla tunelu. To nie tak. Pole jest tablicą routingu działającą w obu kierunkach: wybiera peera dla pakietu wychodzącego i weryfikuje źródło pakietu przychodzącego. Czytanie go jako listy dostępu tworzy konfiguracje, które routują ruch, o który nikt nie prosił.

Jedno pole, dwóch czytających: wybór wychodzący i kontrola źródła

U klienta prefiksy decydują, które cele podróżują do tego peera, a które zostają w zwykłej sieci. Dlatego wpis dla 0.0.0.0/0 przechwytuje każdy cel IPv4, i dlatego import profilu pełnego tunelu wysyła zwykłe przeglądanie przez zdalną maszynę. Wąskie wpisy robią odwrotnie: routują tylko wymienione sieci, a wszystko inne zostawiają tam, gdzie było. Sekcja o routingu kluczy kryptograficznych w dokumentacji WireGuard podaje oba zadania w jednym miejscu: wybór peera wychodzącego i weryfikację źródła przychodzącego.

Na serwerze to samo pole opisuje, których adresów źródłowych może używać każdy peer. To kontrola kryptograficzna, a nie filtr pakietów: pakiet, którego wewnętrzne źródło nie pasuje do listy peera, jest odrzucany wewnątrz WireGuard, zanim zobaczy go jakikolwiek firewall hosta. Oba zadania dzielą jedną listę, i właśnie dlatego lista skopiowana skądinąd zachowuje się źle w miejscu, którego nie uwzględniłeś.

Blok klienta to miejsce, w którym zaczyna się większość tego zamieszania. Tunel dzielony nazywa sieci zdalne, a pełny tunel to to samo pole z domyślnym prefiksem:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Obie formy są same w sobie kompletne i są alternatywami, a nie krokami. Pierwsza wysyła przez tunel tylko te dwie sieci; druga wysyła każdy cel, a wpis ::/0 dodaje IPv6 do domyślnego IPv4. Cokolwiek wybierzesz, te prefiksy są całą decyzją routingu dla tego peera, gdy wg-quick zacznie instalować trasy.

Hub potrzebuje innej listy

Hub wymienia adres tunelu każdego klienta jako prefiks hosta oraz każdą sieć, która naprawdę znajduje się za tym klientem. Kopiowanie szerokiej listy klienta na każdego peera huba mówi hubowi, że wiele peerów może używać tych samych adresów jako źródła, a to nie jest plan adresacji. Pole Endpoint należy do zupełnie innej warstwy: podaje zewnętrzny adres i port peera, nigdy celu wewnątrz tunelu.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

Prefiks hosta niesie adres tunelu, a prefiks sieci niesie to, co jest za klientem, i oba są potrzebne. Bez prefiksu hosta hub nie może zwrócić ruchu samego klienta, a bez prefiksu sieci LAN za nim pozostaje nieosiągalny; peer, za którym nic nie ma, dostaje tylko prefiks hosta.

Pominięcie instalacji tras zostawia lukę

wg-quick, pomocnik, który podnosi interfejs z pliku konfiguracji, instaluje adresy interfejsu i trasy jako część tej pracy. Ustawienie Table = off każe pomocnikowi pominąć pracę z trasami, co nie instaluje zamienników i nie czyni sieci prywatnej osiągalną. Gdy automatyczne trasy już wykonują pracę, wskazanie potrzebnych prefiksów jest jaśniejszą konfiguracją. Wyłączenie zarządzania trasami i pozostawienie zamiennika niezapisanego nie jest projektem, to zaniedbanie.

Podstawowe narzędzie wg zachowuje się inaczej: konfiguruje interfejs i nigdy nie dotyka tras, więc konfiguracja zbudowana bezpośrednio na nim potrzebuje własnych poleceń tras. Instrukcje napisane dla jednego narzędzia mogą wyglądać źle, gdy stosuje się je z drugim. Udany ping to też słaby dowód, bo sprawdza jedną ścieżkę, a nie każdą potrzebną ścieżkę aplikacji.

DNS i IPv6 rozstrzyga się osobno

Sprawdź adres serwera DNS ogłaszany przez tunel i potwierdź, że przez wybrane prefiksy istnieje trasa do tego adresu. Ustawienie resolvera nie czyni resolvera osiągalnym, a zwężenie tunelu może po cichu usunąć trasę, która tam prowadziła. Zbadaj też IPv6 osobno, bo poprawny podział IPv4 nic nie mówi o domyślnej trasie IPv6, która nadal wskazuje na łącze fizyczne. Trzy osobne decyzje mogą zmienić się naraz, gdy edytujesz jeden blok peera.

Następnie otwórz jeden prywatny zasób i jedną zwykłą stronę z znanej konfiguracji początkowej. Jeśli zasób odpowiada, a przeglądanie nadal wychodzi przez połączenie lokalne, podział robi to, o co prosiłeś. Jeśli przeglądanie psuje się w tej samej chwili, tunel przejął trasę domyślną, a lista prefiksów jest miejscem, w którym trzeba szukać.

Powiązane artykuły