WireGuard: dwie połówki tras kontra 0.0.0.0/0 w wg-quick

Dwa prefiksy /1 pokrywają dokładnie te same adresy IPv4 co jeden /0, a ta równość obowiązuje tylko wewnątrz listy dozwolonych prefiksów peera. Przestaje obowiązywać w chwili, gdy narzędzie konfiguracyjne decyduje, jak kierować ruchem, ponieważ Linux wg-quick traktuje domyślny prefiks jako przypadek szczególny, a nie jako arytmetykę. Specjalna gałąź instaluje osobną tabelę, dwie reguły polityki, oznaczenie gniazda i ustawienia trasy odwrotnej, których para połówek tras nigdy nie otrzymuje. Gdy więc po edycji proxy lub przeglądarka przestaje działać, prefiksy są najmniej ciekawą częścią zmiany.

Lista prefiksów to nie cała konfiguracja

AllowedIPs wykonuje dwie prace naraz i tylko jedna z nich dotyczy pokrycia. Dla samego WireGuarda lista to routing klucza kryptograficznego: decyduje, które cele są szyfrowane w stronę peera i których adresów źródłowych ten peer może używać. Dla wg-quick ta sama lista służy też jako specyfikacja tras, a tworzona trasa zależy od tego, w którą gałąź lista przypadkowo trafi. Identyczne pokrycie przy dwóch różnych kształtach listy nie mówi więc nic o identycznym stanie hosta.

Konfiguracja domyślna odbiera tę decyzję z twoich rąk, ponieważ Table jest domyślnie automatyczne, a narzędzie samo wybiera, gdzie wylądują trasy. Inny menedżer sieci, opakowanie dystrybucji lub własna wartość Table ponownie zmieniają wynik, dlatego rada napisana dla jednego hosta może wyglądać źle na następnym.

Co domyślna gałąź dodaje poza trasą

Wpis /0 wysyła wg-quick na ścieżkę trasy domyślnej: osobna tabela routingu otrzymuje trasę domyślną, jedna reguła polityki kieruje tam ruch nieoznaczony, druga reguła utrzymuje bardziej szczegółowe trasy tabeli głównej jako autorytatywne, a interfejs otrzymuje oznaczenie firewalla na własnym gnieździe. To oznaczenie jest strażnikiem pętli. Zaszyfrowane datagramy niosące ruch tunelu wychodzą z ustawionym oznaczeniem, aby reguła kierująca wszystko inne do tunelu nie połknęła własnych pakietów transportowych tunelu.

Para wpisów /1 wybiera natomiast zwykłą ścieżkę trasy. Dwie trasy trafiają do skonfigurowanej tabeli i żaden z otaczających mechanizmów się nie pojawia, nie dlatego, że jest zbędny, ale dlatego, że ta ścieżka kodu nigdy nie została użyta.

Gdzie oba układy się rozchodzą

Rozbieżność ujawnia się najpierw jako rekurencja. Gdy połówki tras są w tabeli głównej, własny adres transportowy peera wpada w prefiks tunelu, więc pakiet, który powinien nieść tunel, pasuje do trasy wskazującej do wnętrza tunelu. Coś musi go wyłączyć: trasa hosta dla bieżącego punktu końcowego, oznaczenie nałożone ręcznie lub reguła właściwa dla interfejsu. Trasa hosta działa, dopóki nie zmieni się adres punktu końcowego, co zdarza się przy punktach końcowych opartych na DNS, klientach mobilnych i konfiguracjach z wieloma peerami.

Po drugie, wszystko, co rozumuje na podstawie oznaczeń, zmienia zachowanie. Przezroczyste proxy, które lokalnie przekierowuje połączenia, tworzy nowe gniazda, których oznaczenia i źródła różnią się od pierwotnego przepływu klienta, a reguły polityki generowane przez domyślną gałąź były częścią tego, co te przepływy rozdzieliło. Czytanie własnego połączenia wychodzącego proxy to inne ćwiczenie niż sprawdzanie, czy pierwotny cel jest osiągalny.

Przeczytaj reguły i oznaczenia przed edycją

Zarejestruj bieżący stan, gdy tunel jest zdrowy, potem ponownie po zmianie, i porównaj oba zrzuty zamiast rozumować z pliku konfiguracji. Uwzględnij reguły polityki, każdą tabelę, oznaczenie interfejsu i zapisane punkty końcowe.

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

Jeśli pierwsza linia wyjścia utraciła regułę ruchu nieoznaczonego, a osobna tabela jest pusta, domyślna gałąź nie działa i żadna arytmetyka prefiksów nie przywróci jej skutków. Oznaczenie zero na interfejsie, który wcześniej je nosił, to ten sam sygnał, widoczny w jednej wartości.

Przećwicz utratę tunelu przed wdrożeniem

Jeśli układ połówek tras jest świadomym wyborem, musi jawnie dostarczyć brakujące elementy: ścieżkę punktu końcowego odporną na zmiany adresu, zamierzone zachowanie przy upadku tunelu i równoważne traktowanie IPv6. Zapisz to jako wymagania, zamiast odkrywać podczas awarii. Następnie przećwicz awarię, bo pełny tunel, który po cichu wraca do fizycznego łącza, jest gorszy od tego, który przestaje działać.

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

Wyszukiwanie trasy powinno rozwiązać punkt końcowy z fizycznego interfejsu bez przechodzenia przez tunel, a zdjęcie interfejsu powinno pozostawić host w stanie, który obiecał projekt. Proxy działające po zamianie dowodzi, że wygenerowany stan hosta miał znaczenie; nie dowodzi, że zapobieganie pętlom i zachowanie w stanie wyłączonym przetrwały edycję.