Uścisk dłoni WireGuard udaje się, ale odpowiedź nie wraca

Niedawne uściski dłoni to dobra wiadomość i znacznie mniejsze twierdzenie niż zdanie, które ludzie chcą napisać. Strony wymieniły uwierzytelnione komunikaty uścisku dłoni. Pakiet aplikacji nadal musi dotrzeć do swojego celu wewnętrznego i wrócić.

Ta przepaść między zdrową płaszczyzną sterowania a cichą płaszczyzną danych to cały temat tutaj. Dwa odczyty tych samych liczników mówią, po której stronie jesteś.

Uścisk dłoni dowodzi kluczy, nie dostarczenia

Uścisk dłoni WireGuard to uzgodnienie kluczy z uwierzytelnianiem. Udaje się, gdy tylko strony mogą się wzajemnie osiągnąć i mają ważne klucze. Routing, polityka zapory i sam cel to pytania, których uścisk dłoni nigdy nie zadaje.

Tunel może więc być doskonale ustanowiony, podczas gdy każdy pakiet w nim jest odrzucany. Źle trasowany pakiet wewnętrzny i odpowiedź, która idzie inną drogą, wyglądają z punktu widzenia klienta tak samo.

Jeden adres wewnętrzny to cały test

Wybierz jeden cel i trzymaj się go. Własny adres tunelu drugiej strony to najprostszy przypadek, a host za nią dodaje dokładnie jeden skok. Przełączanie się między nimi bez notowania zmiany daje wyniki, których nikt nie może porównać.

Następnie spójrz na trasę, którą wybiera klient. Bardziej szczegółowa trasa lokalna może wysłać pakiet gdzie indziej, zanim WireGuard w ogóle zostanie zapytany, i dzieje się tak zawsze, gdy domowa sieć LAN pokrywa się z zakresem zdalnym.

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

Adres, który rozwiązuje się na interfejs fizyczny, już odpowiedział na pytanie. Tunel niczego nie odrzuca. Pakiet nigdy do niego nie wszedł.

Liczniki są dowodem, nie wyrokiem

wg show raportuje bajty wysłane i odebrane na stronę, a te dwie liczby poruszają się niezależnie. Zrób odczyt, wykonaj jedno dozwolone żądanie, a następnie w tej samej minucie zrób kolejny odczyt.

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

Rosnące wysyłanie przy płaskim odbiorze to sygnatura żądania bez odpowiedzi. Nie mówi, czy żądanie zostało odfiltrowane, czy cel był wyłączony, ani czy odpowiedź wyszła inną trasą. To trzy śledztwa z jednym objawem. Rozdziel je, zanim zmienisz jakąkolwiek konfigurację.

Stała liczba bajtów też nie jest progiem sukcesu. Wartości liczników podążają za ruchem, a traktowanie jednej liczby jako dowodu zdrowia daje pewną siebie bzdurę.

Druga strona sama sprawdza pakiet powrotny

Zdalna strona akceptuje pakiet wewnętrzny tylko wtedy, gdy źródło mieści się w jej allowedips. Trasa istniejąca u nadawcy nie wystarcza. Brak wpisu źródła u odbiorcy po cichu odrzuca ruch powrotny.

Zapory hosta stoją za tym sprawdzeniem. Reguła przekazywania, która pozwala interfejsowi tunelu, ale nie podsieci wewnętrznej, akceptuje uścisk dłoni i odrzuca pakiet. Z punktu widzenia klienta wygląda to dokładnie jak martwa druga strona. Host z dwoma interfejsami może też odpowiedzieć z niewłaściwego źródła, a wtedy druga strona odrzuca odpowiedź, której nigdy się nie spodziewała.

Utrzymaj eksperyment uczciwym

Testowanie profilu dostępu zdalnego z tej samej sieci domowej, do której ma dotrzeć, ćwiczy inną drogę niż zamierzona. Przejdź do sieci zewnętrznej i zapisz jej lokalny prefiks, aby oba przebiegi można było porównać.

Mała udana wymiana też nie wyklucza wszystkich problemów z drogą. Większe pakiety mogą zawodzić tam, gdzie przechodzą małe, a filtr dopasowany do rozmiaru lub protokołu może zachowywać się inaczej pod obciążeniem.

Zachowaj uścisk dłoni jako znany działający etap i idź dalej od niego. Następnym użytecznym dowodem jest to, gdzie zatrzymuje się jedno żądanie wewnętrzne, a nie nowy zestaw kluczy i kolejna runda zgadywania.