Peer WireGuard nieosiągalny, gdy inny działa: lista kontrolna

Jeden peer WireGuard przepuszcza ruch, a drugi wykonuje uścisk dłoni, ale nigdy nie dociera do niczego za tunelem. Działający peer mówi ci, że interfejs, port UDP i klucz serwera są prawdopodobnie w porządku. Nie mówi nic o AllowedIPs drugiego peera, jego wewnętrznym adresie źródłowym ani regułach przekazywania pomiędzy nimi. Przejdź listę po kolei i zatrzymaj się na pierwszym kroku, którego warunek nie jest spełniony.

Krok 1: Zapisz ścieżkę, którą powinien przejść pakiet

Dwaj klienci w tym samym koncentratorze nie docierają do siebie automatycznie. W układzie koncentratora i promieni serwer odbiera pakiet na wg0 i musi przekazać go z powrotem z wg0 do drugiego peera, co wymaga przekazywania IP i reguły przekazywania. W bezpośrednim układzie peer do peera każda strona potrzebuje punktu końcowego drugiej strony i adresu jej tunelu w AllowedIPs. Zdecyduj, który układ debugujesz, zanim przeczytasz jakąkolwiek konfigurację.

Oczekiwana ścieżka mówi też, gdzie patrzeć. Jeśli pakiet ma przejść przez koncentrator, nieudanym przeskokiem są albo AllowedIPs nadawcy, albo przekazywanie w koncentratorze, albo AllowedIPs odbiorcy. Jeśli ma iść bezpośrednio, koncentrator jest nieistotny i liczą się pola punktu końcowego na obu peerach.

Krok 2: Porównaj AllowedIPs po obu stronach, nie tylko po jednej

WireGuard używa AllowedIPs jednocześnie jako tablicy routingu i listy dostępu. Przy wysyłaniu adres docelowy jest wyszukiwany w AllowedIPs peera, aby wybrać tunel; przy odbiorze wewnętrzny adres źródłowy musi mieścić się w AllowedIPs peera wysyłającego, inaczej pakiet jest odrzucany. Brakujący zakres po którejkolwiek stronie daje ten sam objaw: transport działa, ładunek znika.

Czytaj stan na żywo, a nie plik, bo przeładowanie mogło po cichu się nie udać: sudo wg show wg0 allowed-ips. Na serwerze wpis nieudanego peera musi zawierać jego adres tunelu, na przykład 10.90.0.3/32. Na kliencie wpis peera serwera musi zawierać cel, który testujesz, czy to adres tunelu koncentratora, czy podsieć zdalna. Nakładające się zakresy czynią wyszukiwanie niejednoznacznym i mogą wybrać peera, którego nie miałeś na myśli, więc trzymaj je osobno.

Krok 3: Sprawdź wewnętrzny adres źródłowy

Klient, który kieruje 10.90.0.3 przez wg0, ale wysyła pakiety ze swojego adresu Wi-Fi, zostanie odrzucony przez odbiorcę, ponieważ źródło nie pasuje do AllowedIPs peera. Potwierdź, co jądro faktycznie wybiera, za pomocą ip route get 10.90.0.3 from 10.90.0.2, i potwierdź adres przypisany do interfejsu tunelu za pomocą ip -brief addr show wg0.

Na odbierającym hoście Linux filtrowanie odwrotnej ścieżki jest drugą bramą. Ścisły rp_filter na interfejsie, do którego należy trasa powrotna, może odrzucić ruch tunelu, którego ścieżka powrotna nie pasuje do interfejsu, przez który przyszedł. Sprawdź wartość efektywną, zanim go wyłączysz; w wielu topologiach właściwą poprawką jest trasa, a nie poluzowany filtr.

Krok 4: Przejrzyj przekazywanie w koncentratorze i ścieżkę powrotną

Jeśli koncentrator ma przekazywać ruch między peerami, jądro potrzebuje net.ipv4.ip_forward=1, a zapora musi akceptować przekazywany przepływ: wejście na wg0, wyjście na wg0, od adresu tunelu nadawcy do adresu odbiorcy. Częstym błędem jest reguła wejściowa, która akceptuje UDP 51820, ale nie ma reguły przekazywania], więc uścisk dłoni się udaje, a ładunek ginie. Wypisz obowiązujące reguły za pomocą sudo nft list ruleset lub odpowiednika dla twojego menedżera zapory.

Następnie sprawdź odpowiedź. Host docelowy musi mieć trasę powrotną do nadawcy, albo przez koncentrator, albo przez własną bramę. Jeśli koncentrator wykonuje też NAT na podsieci tunelu, potwierdź, że tłumaczenie dotyczy przekazywanego przepływu i że odpowiedź dociera do koncentratora, zanim stan wygaśnie. Jednokierunkowa awaria, która wygląda na problem z kluczem, to często właśnie ta trasa powrotna.

Na koniec oddziel uścisk dłoni od danych. Peer, który kończy uścisk dłoni, ale zatrzymuje się przy dużych transferach, zwykle ma problem z MTU lub MSS na tej konkretnej ścieżce, a nie problem z AllowedIPs. Testuj najpierw małym pingiem, potem pełnowymiarowym, i porównaj oba peery.

Krok 5: Zmień jedną rzecz i zostaw działający peer nietknięty

Wprowadź jedną zmianę na nieudanej ścieżce i ponownie przetestuj oba peery. Zastąpienie AllowedIPs każdego peera przez 0.0.0.0/0 to najszybszy sposób zepsucia peera, który już działał, ponieważ zmienia decyzję routingu dla całego ruchu na tym interfejsie. Edytuj ten jeden wpis, przeładuj i odczytaj stan na żywo.

Zapisz, która ścieżka się udała, która nie, oraz dokładne wyjście polecenia dla każdej. To porównanie jest warte więcej niż ogólny raport, że VPN jest zepsuty, i to o nie najpierw zapyta następna osoba.