WireGuard wysyła dane, ale nic nie wraca: która strona?

Liczniki wysyłania, które rosną, podczas gdy licznik odbioru stoi na zerze, opisują kierunek, a nie diagnozę. Ten sam odczyt pojawia się, gdy partner nigdy nie ukończył uścisku dłoni, gdy cel wybrał niewłaściwego partnera, gdy druga strona nie ma trasy powrotnej i gdy filtr wyrzuca odpowiedź w drodze do domu. Każdy z tych przypadków naprawia się w innym miejscu.

Porównanie, które skraca pracę, dotyczy żądania, które nigdy nie opuściło tunelu, i odpowiedzi, która nigdy nie wróciła. Jeden zrzut na właściwym interfejsie rozstrzyga między nimi.

Liczniki opisują objętość, nie kierunek usterki

Liczniki WireGuard zapisują, co interfejs przekazał partnerowi i co od niego otrzymał. Nie mówią, który cel, który partner albo która połowa wymiany zawiodła. Ruch w tle czyni sumy jeszcze mniej informacyjnymi, ponieważ niektóre bajty mogą być komunikatami podtrzymania lub niepowiązanymi strumieniami. Czytaj je jako wskaźnik, że interfejs jest aktywny, a potem przestań traktować je jako dowód.

Pierwszym użytecznym faktem jest to, czy uścisk dłoni jest aktualny. Bez niego nic nie zostało zaszyfrowane dla tego partnera, a licznik odbioru nie ma powodu się zmieniać.

Wybór partnera albo droga odpowiedzi: dwa wyjaśnienia

Pierwsze wyjaśnienie jest takie, że pakiet nigdy nie dotarł do zamierzonego partnera, bo trasa wskazywała gdzie indziej albo dozwolone prefiksy partnera nie obejmowały celu. Drugie jest takie, że pakiet dotarł, a odpowiedź nie mogła wrócić, co jest problemem routingu na dalekim końcu. Tabela rozdziela je według tego, co zaobserwowałbyś w każdym punkcie.

Czytaj tabelę od góry. Brak uścisku dłoni kieruje cię do kluczy, punktów końcowych i drogi zewnętrznej, bo nie ma jeszcze nic innego do zbadania. Aktualny uścisk dłoni z żądaniem widocznym na serwerze przenosi problem do kierunku powrotnego, gdzie decyduje własna tabela routingu celu. Żądanie, które nigdy nie pojawia się na serwerze, jest problemem wyboru, a dozwolone prefiksy na obu partnerach to pierwsza rzecz do porównania.

Dwa z tych czterech wierszy naprawia się na kliencie, a dwa na serwerze. Wiedza, w której parze jesteś, to większość pracy.

Gdzie znikają odpowiedzi

Odpowiedź opuszcza cel, dociera do interfejsu tunelu serwera i jest szyfrowana dla partnera, którego dozwolone adresy pasują do wewnętrznego adresu klienta. Jeśli to dopasowanie zawiedzie, odpowiedź jest po cichu odrzucana, co od strony klienta wygląda dokładnie jak awaria sieci. Jeśli odpowiedź jest zaszyfrowana, a własny filtr klienta ją odrzuca, objaw jest znów identyczny. Oba przypadki wymagają zrzutu, a nie licznika.

Najsilniejszą wersją tego błędu jest serwer, który przekazuje pakiety za klienta, ale nie ma trasy powrotnej do wewnętrznego zakresu klienta. Przyjmuje żądanie, wysyła odpowiedź w stronę swojej domyślnej bramy, a tunel nigdy jej nie widzi. Szeroka reguła tłumaczenia dodana na serwerze ukrywa tę usterkę zamiast naprawić trasę.

Przetestuj jeden cel od początku do końca

Wybierz jeden cel w zakresie partnera i przetestuj go, gdy uścisk dłoni jest wyraźnie aktualny. Poniższe polecenia czytają stan partnera, wybraną trasę i obie strony wymiany. Uruchom zrzut na interfejsie, którego faktycznie używają szyfrowane pakiety.

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

Zrzut pokazujący żądanie na interfejsie tunelu bez niczego wracającego jest odpowiedzią ze strony serwera, a tabela routingu celu jest następnym miejscem do sprawdzenia. Jeśli nie pojawia się zupełnie nic, pakiet poszedł inną drogą, więc podejrzana jest trasa lokalna. Wymiana widoczna w obu zrzutach bez postępu w aplikacji przenosi pytanie na rozmiar pakietu albo na filtr, którego statystyki interfejsu nigdy nie pokazują. Trzymaj w teście jeden cel i jednego klienta, bo druga zmienna zamienia dowód z powrotem w wrażenie.

Jeśli nazwy zawodzą, a dozwolony adres działa, odpowiedź jest w DNS, a nie w tunelu. Jeśli zatrzymują się tylko duże transfery, zbadaj rozmiar pakietu osobno.