VPN UDP milczy przy skanowaniu portów? Dlaczego tak się dzieje
WireGuard i utwardzony OpenVPN odrzucają datagramy, które nie przejdą uwierzytelnienia, bez odpowiedzi. Cisza od skanera to oczekiwane zachowanie, a nie zamknięty port.
Skanujesz port VPN, nie otrzymujesz odpowiedzi i wnioskujesz, że usługa nie działa albo że zapora jest zamknięta. W przypadku WireGuarda oraz kanałów kontrolnych OpenVPN, które niosą własne uwierzytelnienie, ten wniosek nie wynika. Datagram bez ważnego materiału uwierzytelniającego jest odrzucany bez odpowiedzi, więc cisza to właśnie to, jak zdrowa usługa wygląda z zewnątrz. Sonda jest błędna, zanim błędny jest tunel.
Cisza to protokół, a nie awaria
UDP nie ma zestawiania połączenia, więc nie ma SYN ani potwierdzenia, które pozwoliłoby skanerowi odróżnić port otwarty od filtrowanego. Sonda przychodzi jako izolowany datagram, a usługa sprawdza, czy odpowiada on oczekiwanemu protokołowi. Gdy nie odpowiada, pakiet jest odrzucany, a odrzucenie jest udokumentowanym zachowaniem, nie usterką.
WireGuard weryfikuje kryptograficznie swoje komunikaty handshake i ignoruje wszystko, co się nie powiedzie. OpenVPN z tls-auth lub tls-crypt robi to samo dla swojego kanału kontrolnego. W obu przypadkach dowolny ładunek nigdy nie dociera do etapu zwróconego do użytkownika, więc nie ma czym odpowiedzieć i nie ma błędu do zwrócenia.
TCP dałby ci reset z zamkniętego portu. UDP zostawia niejednoznaczność, którą skanery rozwiązują, wypisując otwarty lub filtrowany zamiast zgadywać.
Co skaner może, a czego nie może wywnioskować
Wynik skanowania jest tylko tak informacyjny, jak wysłany ładunek. Uporządkuj możliwe obserwacje według tego, co każda z nich naprawdę potwierdza:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
Trzeci wiersz czytaj jako jedyny pozytywny test na liście. Wymaga prawdziwego profilu, prawdziwego klucza i właściwego punktu końcowego, a tego właśnie ogólny skaner nie ma.
Spójrz na oba końce ścieżki
W przypadku serwera, którym administrujesz, przechwyć ruch na interfejsie, zanim wyciągniesz jakikolwiek wniosek, a potem zapytaj usługę, co zobaczyła. Oba polecenia wymagają root na bramie:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showJeśli na interfejsie nie pojawia się żaden pakiet, ścieżka odrzuciła go, zanim usługa cokolwiek zobaczyła, a następnym przystankiem jest routing i filtrowanie. Jeśli pakiety docierają, ale żaden handshake się nie kończy, usługa jest osiągalna, a niezgodność leży w kluczach, konfiguracji punktu końcowego lub wersji protokołu. To porównanie odpowiada na pytanie, na które skaner nie potrafił. Uruchom je, gdy prawdziwy klient próbuje się połączyć, a nie gdy skaner się powtarza.
Zmień test, nie ochronę
Kuszącym skrótem jest wyłączenie ochrony kanału kontrolnego, aby diagnostyka otrzymała odpowiedź. To wymienia prawdziwą właściwość bezpieczeństwa na ładniejszy wynik skanowania i jest to zły kierunek. Zamiast tego użyj ważnego profilu z zatwierdzonej sieci i zanotuj punkt końcowy oraz czas, aby porównanie było powtarzalne.
Najbardziej przydatny test jest różnicowy: ten sam profil na ścieżce, która działa, i na tej, która nie działa. Jeśli działająca ścieżka daje handshake, a zawodna ścieżka nie daje nic na interfejsie, zlokalizowałeś przerwanie, niczego nie osłabiając.
Nieodpowiedziany pakiet UDP nie dowodzi więc ani tego, że serwer jest offline, ani tego, że jest bezpieczny. Dowodzi, że ta sonda, na tej ścieżce, w tej chwili nie została zaakceptowana.