Prefiks hosta w WireGuard: dlaczego jeden adres działa, a reszta nie

Tunel działa, handshake odbywa się co dwie minuty, a dokładnie jeden adres po drugiej stronie odpowiada. Pingi do adresu tunelu peera działają; nic za nim nie działa. Ktoś czyta konfigurację interfejsu, widzi prefiks hosta i dochodzi do wniosku, że maska jest zła. Rozszerzenie jej do /24 naprawia ping na jakiś czas, a potem psuje coś innego. Prefiks nigdy nie był przyczyną, a brakująca trasa to nie ta, którą kontroluje maska.

Co faktycznie tworzy prefiks interfejsu

W Linuksie przypisanie adresu do interfejsu tworzy trasę połączoną dla tego prefiksu. Przypisz prefiks hosta, a trasa połączona obejmie jeden adres. Przypisz /24, a obejmie 256, z których każdy jest teraz uznawany za osiągalny przez to łącze.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Prefiks hosta to całkowicie normalny wybór dla tunelu punkt-punkt, bo po drugiej stronie jest dokładnie jeden peer. Trzecie polecenie jest tym, które odpowiada na pytanie użytkownika: mówi, którego interfejsu jądro użyłoby dla tego celu, i nie pokaże nic użytecznego, jeśli żadna trasa nie pasuje.

To całe wyjaśnienie objawu. Jeden adres odpowiada, bo istnieje dla niego trasa połączona albo bo lista dozwolonych peera przypadkiem go zawiera. Wszystko inne nie ma trasy i jest odrzucane, zanim WireGuard w ogóle wejdzie w grę. Tunel jest przez cały czas zdrowy, dlatego licznik handshake wciąż wygląda zachęcająco.

AllowedIPs to dwie reguły pod jedną nazwą

Lista dozwolonych dla peera w WireGuard wykonuje dwie prace naraz, a składnia konfiguracji sprawia, że wyglądają jak jedna. Na wejściu autoryzuje, jakie adresy źródłowe peer może przedstawić. Na wyjściu wybiera, do którego peera trafi pakiet, znajdując najbardziej szczegółowe dopasowanie.

Żadna z tych prac nie jest routingiem. Jądro nadal musi zdecydować, że pakiet należy do interfejsu tunelu, zanim WireGuard na niego spojrzy, a ta decyzja pochodzi z tabeli tras. Wpis peera z szeroką listą dozwolonych nie instaluje sam z siebie trasy.

Dlatego konfiguracja może wyglądać kompletnie, a zachowywać się asymetrycznie. Klient wysyła do drugiej strony, bo istnieje trasa, a odpowiedzi nigdy nie wracają, bo lista dozwolonych drugiej strony nie autoryzuje źródła klienta albo druga strona nie ma drogi powrotnej. Oba kierunki to osobne decyzje z osobnymi trybami awarii. Zapisanie, który z nich testujesz, to połowa diagnozy.

Skąd bierze się trasa

Jeśli używasz wg-quick, trasy są generowane za ciebie z listy dozwolonych każdego peera, chyba że ustawiłeś Table = off i sam przejąłeś kontrolę. To udokumentowane zachowanie narzędzia i powód, dla którego konfiguracja bez jawnych dyrektyw tras nadal działa.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Porównaj listę dozwolonych z trasami, które faktycznie istnieją. Peer, który pozwala na całą podsieć, ale utworzył tylko trasę hosta, oznacza, że pomocnik nigdy nie zadziałał albo że zarządzasz interfejsem bezpośrednio za pomocą wg i ip, a wtedy nic nie generuje za ciebie tras.

Gdy zarządzasz nim ręcznie, trasa to jedna linia, a jej kształt jest jawny: cel przez interfejs, bez bramy, bo łącze jest punkt-punkt. Dodanie jej nie jest obejściem problemu ze złym prefiksem; to brakująca połowa projektu, który świadomie wziął na siebie routing.

Szerszy prefiks nie dodaje wpisu peera

Kusząca poprawka to zmiana adresu na /24, żeby trasa połączona objęła sieć LAN serwera. Wygląda na to, że działa, a powód, dla którego wygląda na działającą, to fakt, że trasa połączona teraz pasuje, a nie to, że WireGuard nauczył się czegoś nowego.

Zrobiłeś też coś jeszcze: zgłosiłeś cały zakres jako bezpośrednio osiągalny przez to łącze, łącznie z adresami należącymi do innych peerów albo do sieci LAN, która faktycznie jest za serwerem. Ruch do tych adresów wchodzi teraz do tunelu, a czy wyjdzie po drugiej stronie, zależy od routingu i list dozwolonych samego serwera.

Strona kryptograficzna nie jest w żaden sposób naruszona. WireGuard nadal potrzebuje wpisu na liście dozwolonych obejmującego cel, aby wybrać peera, a druga strona nadal potrzebuje wpisu obejmującego twoje źródło, aby go zaakceptować. Szerszy prefiks interfejsu nie dostarczy ani jednego, ani drugiego.

Potwierdź oba kierunki, zanim cokolwiek zmienisz

Potraktuj oba końce osobno i zapisz, co mówi każdy z nich. Na kliencie trasa i wpis peera; na serwerze lustrzane odbicie plus własna droga powrotna:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Przechwycenie rozstrzyga spory o kierunek. Jeśli pakiety wychodzące pojawiają się na interfejsie tunelu, a serwer nic nie loguje, drugi koniec je odrzuca, zwykle dlatego, że twoje źródło jest poza jego listą dozwolonych. Jeśli nie pojawia się nic, trasa brakuje albo wskazuje gdzie indziej.

Potem napraw węższy koniec. Wpis na liście dozwolonych po stronie serwera dla adresu twojego klienta i wpis po stronie klienta dla podsieci docelowej to normalny kształt, i pozostawia prefiks interfejsu w spokoju. Poszerzaj prefiks tylko wtedy, gdy plan adresacji naprawdę chce wspólnej podsieci na tym łączu, i rób to jako zmianę planu, a nie krok debugowania.