WireGuard działa dopiero po wysłaniu przez serwer: znajomość punktu końcowego

Tunel wydaje się działać dopiero po tym, jak serwer najpierw coś wyśle. Zacznij od klienta i nic się nie dzieje, odczekaj kilka sekund, spróbuj ponownie i się udaje. Zwykła diagnoza to zepsuty NAT, a zwykła diagnoza jest błędna. Zmieniło się to, że jedna strona poznała, gdzie mieszka druga.

Znajomość punktu końcowego, nie osiągalność

Strona WireGuard nie rozpocznie uścisku dłoni, dopóki nie wie, gdzie go wysłać. Konfiguracja podaje to jako punkt końcowy z adresu i portu, a stan działania śledzi punkt końcowy, w który obecnie wierzy.

wg show wypisuje obie strony tego obrazu, a strona bez punktu końcowego w wyniku nie może nic rozpocząć, choćby jej klucz publiczny i dozwolone prefiksy były jak najbardziej poprawne. Porównaj widok klienta z widokiem serwera, zanim zmienisz jakąkolwiek regułę, bo oba często nie zgadzają się co do tego, kto co wie.

Jak strona poznaje punkt końcowy

WireGuard jest celowo cichy. Gdy poprawnie uwierzytelniony pakiet przychodzi z adresu, którego strona się nie spodziewała, implementacja aktualizuje punkt końcowy tej strony na nowe źródło i właśnie tak działa roaming na laptopie, który zmienia sieci. To zachowanie wyjaśnia zależność od kierunku: jeśli serwer wyśle pierwszy, a jego pakiet dotrze do klienta, klient poznaje bieżący adres serwera i może odpowiedzieć. Do tego czasu nie ma gdzie wysyłać. Mechanizm to uwierzytelniony roaming, a nie skrót zaufania przy pierwszym użyciu, ponieważ pakiet musiał być ważny, zanim punkt końcowy się przesunął.

Dokumentacja narzędzi dla wg opisuje tę aktualizację i warto ją przeczytać raz, jeśli zamierzasz projektować wokół tego.

Tłumaczenie ze stanem dodaje własny kierunek

Gdy UDP przechodzi przez tłumaczącą bramę, brama tworzy stan dla pierwszego pakietu, który widzi. RFC 4787 opisuje to zachowanie i limity czasu, które w końcu usuwają mapowanie. Bezczynne mapowanie wygasa, a pakiet przychodzący z dalekiej strony jest wtedy odrzucany przez bramę, zanim dotrze do hosta. Tunel, który działał cały ranek, przestaje odpowiadać po południu dokładnie z tego powodu.

To drugi i niezależny mechanizm, który daje ten sam objaw kierunkowy. Zarówno znajomość punktu końcowego, jak i stan tłumaczenia muszą być poprawne, a naprawa jednego nie naprawia drugiego.

Skonfiguruj kierunek, którego naprawdę chcesz

Dla klienta, który musi rozpocząć połączenie, umieść punkt końcowy serwera w sekcji stron klienta i zostaw go tam. Poleganie na tym, że serwer wyśle pierwszy, to poleganie na przypadku w kolejności ruchu, który zmieni się w spokojnej sieci. Konfiguracja powinna deklarować zamierzony kierunek, a nie go odkrywać.

Dla strony za tłumaczeniem, która musi pozostać osiągalna, włącz trwały keepalive po tej stronie. Keepalive co 25 sekund to zwykła wartość początkowa, a jego celem jest utrzymanie mapowania otwartym, a nie testowanie tunelu. Wybierz jedną stronę, która go niesie, bo włączenie po obu stronach podwaja ruch i szum w logach, nie poprawiając wyniku.

Porównaj stan przed i po wyzwalaczu

Przechwyć oba widoki w chwili awarii, a potem ponownie po wysłaniu przez serwer. Pierwsze polecenie pokazuje punkty końcowe i wiek uścisku dłoni. Drugie pokazuje, czy istnieje wpis tłumaczenia dla portu. Przechwycenie pokazuje, który kierunek naprawdę przeszedł przez przewód, a sprawdzenie trasy potwierdza, że klient nie wysyła tego ruchu zupełnie gdzie indziej.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Zapisz kolumnę punktu końcowego i wpis tłumaczenia razem. Strona bez punktu końcowego i brama bez mapowania to dwa różne błędy. Tylko jeden z nich naprawia keepalive.