Uścisk dłoni WireGuard działa, usługa nie

Uścisk dłoni się kończy, klient pokazuje świeży licznik transferu, a żądanie do usługi na tym samym serwerze nadal zawodzi. Ta kombinacja myli ludzi, bo tunel ewidentnie działa. Nie zostało dowiedzione lokalne dostarczenie: pakiet dotarł do hosta, a host nadal musi go przyjąć na właściwym gnieździe i przekazać procesowi z uprawnieniem do odpowiedzi. Przejdź te trzy punkty kontrolne po kolei.

Zatrzymaj się na pierwszym, który nie zachodzi, i nie dodawaj reguł dla pozostałych.

Uścisk dłoni dowodzi tylko tunelu

Uścisk dłoni WireGuard ustanawia klucze między peerami i autoryzuje ruch dla zakresów, które każdy peer wymienił. Nie mówi nic o tym, które procesy nasłuchują na serwerze, ani o tym, czy zapora hosta przyjmuje pakiety adresowane do jednego z jego własnych adresów.

Właśnie tę ostatnią różnicę najczęściej się przeocza: ruch do samego hosta to wejście lokalne, natomiast ruch przechodzący przez hosta gdzie indziej to przekazywanie. Obsługują je różne łańcuchy zapory i różne ustawienia. Sprawdzanie niewłaściwego łańcucha kosztuje popołudnie i zwraca liczniki, które wyglądają niewinnie.

Przeczytaj nasłuch i trasę

Na kliencie potwierdź, że adres tunelu serwera jest routowany do tunelu. Na serwerze potwierdź, że gniazdo istnieje na adresie używanym przez klienta i że proces za nim jest tym zamierzonym.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Nasłuchujący na 127.0.0.1 nigdy nie odpowie na żądanie adresowane do 10.66.0.1, cokolwiek dopuszcza zapora. Nasłuchujący na adresie ogólnym odpowie, chyba że reguła go zablokuje. Lista gniazd rozstrzyga więc połowę przypadków, zanim sprawdzi się jakąkolwiek regułę. Port i adres razem decydują, czy żądanie może dotrzeć.

Porównaj adres używany przez klienta z adresem, który serwer faktycznie ma na interfejsie tunelu. Nieaktualna konfiguracja po którejkolwiek stronie tworzy żądanie poprawnie routowane do peera, który tego adresu nie ma.

Stosuj reguły dla wejścia lokalnego, nie dla przekazywania

Jeśli pakiet dotrze, a gniazdo istnieje, pozostałą granicą jest polityka wejścia. Reguła zezwalająca na przekazywanie nie zezwala na dostarczenie lokalne, a reguła ograniczona do jednego interfejsu może nie pasować do oczekiwanej nazwy interfejsu tunelu.

Testuj jednym dozwolonym portem do zamierzonej usługi, zamiast otwierać host. Następnie sprawdź autoryzację samej aplikacji: lista dozwolonych, wymóg konta lub powiązanie z konkretną nazwą hosta mogą odrzucić żądanie, które sieć dostarczyła skutecznie.

Zostaw sprawdzanie certyfikatów na miejscu. Nieoczekiwana tożsamość certyfikatu to informacja o tym, który host odpowiedział, a nie przeszkoda do obejścia. Klikanie przez nią ukrywa jedyną wskazówkę identyfikującą niewłaściwą usługę.

Oddziel awarie nazwy, rozmiaru i tożsamości

Usługa, która działa po adresie, ale zawodzi po nazwie, to problem DNS, a poprawka należy do konfiguracji resolvera wysyłanej do klienta, nie do zapory. Usługa, która odpowiada na małe żądania, ale zacina się na większych odpowiedziach, wskazuje na rozmiar pakietu i MTU, co jest zupełnie innym dochodzeniem.

Błąd HTTPS wskazujący niewłaściwy host zwykle oznacza, że żądanie dotarło do innej usługi, często dlatego, że ten port zajmuje proxy lub inny nasłuch. Przeczytaj temat certyfikatu i porównaj go z hostem, do którego chciałeś dotrzeć. To porównanie nic nie kosztuje i często kończy dochodzenie.

Zapisz, który punkt kontrolny zawiódł: gniazdo, reguła wejścia czy polityka aplikacji. Ta jedna linia odróżnia awarię sieci od decyzji o autoryzacji. Powstrzymuje też następną osobę przed otwieraniem portów, które nigdy nie były problemem.