Port VPN milczy? Listener, adres bindowania czy zapora hosta

VPN nic nie odpowiada na swoim porcie, a dwie możliwe przyczyny wymagają przeciwstawnych napraw: albo żaden proces nie otworzył gniazda, albo gniazdo istnieje i coś między maszynami zatrzymuje pakiety. Jedno polecenie rozstrzyga pierwszą połowę tego pytania, dlatego trafia przed każdą regułą zapory. Kolejność poniżej usuwa po jednym wyjaśnieniu na krok, zamiast dodawać kolejne przypuszczenie. To właśnie zgadywanie między tymi dwiema zmienia dziesięciominutową diagnozę w cały wieczór.

Załóż, że możesz zalogować się na serwer i że klient to prawdziwy profil, a nie skaner. Oba założenia się liczą, bo ogólna sonda nie odpowie na pytanie specyficzne dla protokołu.

Czy gniazdo w ogóle istnieje

Zacznij od tego, co usługa mówi o sobie: czy wystartowała i, co użyteczniejsze, jaki był jej pierwszy błąd startu. Błąd parsowania, brakujący klucz albo błąd bindowania nie pozwalają listenerowi w ogóle powstać, a proces może zakończyć się tak cicho, że wiersz statusu czyta się niejednoznacznie. Jednostka zgłaszająca aktywność nie jest sama dowodem, bo proces główny może żyć, podczas gdy komponent, który miał zbindować port, już się poddał.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

Lista gniazd to fakt, na którym opiera się reszta diagnozy. Czytaj kolumnę adresu lokalnego, a nie sam port, bo właśnie w tej kolumnie widać bindowania na loopback i na niewłaściwy interfejs. Listener, który istnieje na 127.0.0.1, działa bezbłędnie i nadal jest niewidoczny dla twojego laptopa.

Na jakim adresie i w jakiej rodzinie gniazdo odpowiada

Dwa błędy wyglądają z perspektywy klienta identycznie i wyjaśniają większość zgłoszeń "nieosiągalne". Serwer zbindowany na adres loopback nigdy nie przyjmuje ruchu z innej maszyny, a serwer zbindowany tylko na adres IPv4 nigdy nie odpowie klientowi wybierającemu adres IPv6 tego samego hosta. Zanim cokolwiek założysz o polityce, porównaj adres w tabeli gniazd z adresem, który klient faktycznie wybiera, znak po znaku.

Ograniczenie listy do jednego portu utrzymuje ją czytelną, gdy host uruchamia kilka usług. Filtr sport bierze port razem z transportem, który testujesz:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

Kolumna protokołu zmienia całą odpowiedź

Tabela gniazd indeksuje zarówno protokół, jak i port, i są to dwa niezależne wpisy. Usługa odpowiadająca na TCP na 1194 nie mówi nic o tym, czy coś nasłuchuje na UDP 1194, a klient zawsze użyje tylko jednego z nich. Potwierdź, który transport wybiera konfiguracja serwera i który wysyła profil klienta, a potem szukaj dokładnie tego wiersza.

UDP ma drugi zwój: nieuwierzytelniona sonda nie jest błędem, na który usługa musi odpowiedzieć. Skan, który zgłasza port jako cichy, zmierzył powściągliwość usługi, a nie jej dostępność, więc testuj prawdziwym klientem i profilem.

Jedna próba, trzy miejsca do zajrzenia

Z zatwierdzonego klienta wykonaj dokładnie jedną próbę i zapisz czas co do sekundy. Potem przeczytaj trzy źródła dla tego okna: regułę sieciową lub konsolę dostawcy, liczniki lub log zapory hosta oraz własny log usługi. Zrobienie tego raz sprawia, że trzy relacje są porównywalne, i kosztuje mniej niż powtarzanie próby, której znacznika czasu nikt nie zapisał.

Dwa wyniki wskazują przeciwne kierunki. Jeśli żaden pakiet nie dotarł do hosta, ścieżka go odrzuca, a listener jest nieistotny. Jeśli pakiet dotarł do gniazda, a usługa go odrzuciła, ścieżka jest w porządku i odpowiedź leży w protokole, kryptografii lub poświadczeniach. Otwieranie portu dla usługi, która już przyjęła połączenie, utrudnia następną diagnozę, a nie ułatwia.

Nazwij etap, zanim zmienisz regułę

Negocjacja, która się zaczyna, i uwierzytelnianie, które zawodzi, to jedna awaria, a tunel, który powstaje, gdy przekazywanie staje, to zupełnie inna. Nazwanie etapu najpierw trzyma naprawę wąsko: problemu z poświadczeniami nie naprawia reguła zapory, a problemu ze ścieżką danych nie naprawia restart.

Użyj najwęższej diagnozy, która odpowiada na pytanie. Tymczasowa obserwacja pakietów na jednym porcie, pod kontrolą administratora, jest rozsądnym narzędziem; wyłączenie całej zapory nie jest, bo wynik staje się niemożliwy do przypisania. Dokumentacja ss obejmuje filtry użyte powyżej, i to tańszy pierwszy krok niż jakiekolwiek przechwytywanie. Zapisz, którą z dwóch gałęzi udowodniłeś, a następne wystąpienie zaczyna się od znanej odpowiedzi.