Skannery wypisują otwarty lub filtrowany dla portu UDP, a wniosek zwykle przychodzi w ciągu sekund: tunel jest zepsuty. Może tak być, ale skan tego nie wykazał. UDP nie niesie żadnego uścisku dłoni połączenia, a WireGuard nie odpowiada na nic, czego nie może uwierzytelnić, więc cisza jest oczekiwaną odpowiedzią na większość sond.

Pracuj zamiast tego od klienta na zewnątrz i traktuj skan jako jeden słaby punkt danych wśród kilku.

Co skaner może, a czego nie może zobaczyć

Skaner UDP wysyła ładunek i czeka. Jeśli wróci ICMP port-unreachable, może zgłosić port jako zamknięty. Jeśli nic nie wróci, wynik jest niejednoznaczny z założenia: filtrowana ścieżka, nieobecny host i działająca usługa, która zignorowała ładunek, dają tę samą ciszę. Trzy różne stany, jeden ciąg wyjściowy.

WireGuard celowo pogarsza tę niejednoznaczność. Protokół przyjmuje pakiet tylko wtedy, gdy się uwierzytelni, więc sonda z niewłaściwymi kluczami jest odrzucana bez odpowiedzi. Nie ma banera, ciągu wersji ani komunikatu błędu do pobrania odcisku palca.

Test TCP na tym samym numerze portu nie testuje niczego powiązanego. Ćwiczy inny nasłuch, który może nie istnieć, a jego odmowa nic nie mówi o UDP.

Otwarte filtrowane stany opisują więc niepewność skanera dokładniej niż twój serwer.

Przejdź prawdziwego klienta od profilu do środka

Zacznij od widoku samego klienta. Czy interfejs ma adres, czy konfiguracja wskazuje właściwy punkt końcowy i czy licznik uścisku dłoni porusza się, gdy próbowane jest połączenie? Klient, który nigdy nie wysłał pakietu, i klient, którego pakiety zostały odrzucone, wyglądają identycznie w oknie stanu. Rozróżniają ich tylko liczniki, więc najpierw przeczytaj liczniki.

Następnie obserwuj stronę serwera podczas jednej autoryzowanej próby, zamiast uruchamiać osobny skan z trzeciego miejsca:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

Pierwsze polecenie raportuje ostatni uścisk dłoni na peer, co jest bezpośrednim dowodem, że uwierzytelniona wymiana została ukończona. Drugie pokazuje, czy pakiety dla nasłuchu w ogóle docierają, co oddziela problem ścieżki od problemu konfiguracji w jednym kroku.

Jeśli przechwytywanie nic nie pokazuje, pakiet nigdy nie dotarł do hosta, a konfiguracja tunelu nie jest podejrzana. Jeśli pokazuje pakiety przychodzące z oczekiwanego adresu, podczas gdy uścisk dłoni pozostaje na zero, klucze lub dozwolone adresy peera są następnym miejscem do sprawdzenia.

Koreluj na serwerze, gdy nim administrujesz

Potwierdź, że nasłuch istnieje i że zapora dostawcy zezwala na port UDP. Reguła zapory hosta i grupa zabezpieczeń w chmurze to dwie niezależne bramy i każda z nich może odrzucić pakiet, który druga przepuściła. Sprawdź obie względem rzeczywistego portu w konfiguracji, a nie portu, który pamiętasz.

Adres ma znaczenie tak samo jak port. Serwer nasłuchujący na konkretnym adresie nie odpowie na pakiet, który dotrze na inny, a host z wieloma interfejsami może odebrać sondę na interfejsie, którego nie zamierzałeś.

Trzymaj każdy test w systemach, które masz prawo testować. Użyteczne porównanie to jedno prawdziwe podejście klienta i oczekiwana ścieżka serwera, a nie szersze przemiatanie adresów, które przypadkiem należą do tego samego dostawcy.

Uczciwe czytanie wyniku skanu

Skan to tani sposób sprawdzenia, czy host istnieje i czy port nie jest oczywiście blokowany przez urządzenie pośredniczące. Nie jest dowodem osiągalności dla uwierzytelnionego protokołu i z pewnością nie jest testem konfiguracji.

Silniejszym dowodem jest ukończony uścisk dłoni od klienta, na którym naprawdę ci zależy, a następnie żądanie, które korzysta z tunelu i otrzymuje odpowiedź. Ta sekwencja ćwiczy klucze, dozwolone adresy, obie zapory i ścieżkę powrotną za jednym razem.

Gdy prawdziwa próba się nie powiedzie, awarię nadal trzeba diagnozować za pomocą liczników klienta i przechwytywania na serwerze, a nie kolejnej sondy. Opis protokołu wyjaśnia, dlaczego nieuwierzytelniony pakiet nie otrzymuje odpowiedzi, i to jest cały powód, dla którego wynik skanu jest niejednoznaczny.

Powiązane artykuły