OpenVPN mówi połączony, a ruch się nie porusza, zdanie, które obejmuje co najmniej pięć niepowiązanych awarii. Edytowanie reguł zapory, zanim wiesz, która warstwa zawodzi, mnoży niewiadome i zostawia następnemu inżynierowi bałagan. Pracuj zamiast tego od procesu na zewnątrz, bo każdy krok poniżej albo oczyszcza jeden etap, albo zawęża miejsce, w którym pakiet umiera. Kolejność ma tu znaczenie: przechwycenie zrobione, zanim wiesz, który adres jest przypisany, coś udowodni, tylko nie to, czego potrzebujesz.

Gniazdo jest albo przypisane, albo nie

Usługa zgłaszająca aktywność nadal może być przypisana do adresu lub transportu, którego nigdy nie zamierzałeś. Zapytaj samego gniazda: ss -lunp wymienia nasłuchy UDP, a ss -ltnp TCP, i kolumna warta czytania to adres lokalny, a nie stan.

Pusta odpowiedź zwykle oznacza jedno z trzech: proces zakończył się po starcie, wczytał inny plik konfiguracyjny albo nasłuchuje na innym adresie niż ten, na który się dzwoni.

ss -lunp | grep 1194
ss -ltnp | grep 1194

Dyrektywa local przybija nasłuch do jednego adresu, więc klient kierowany gdzie indziej na tym samym hoście jest odrzucany, podczas gdy usługa z zewnątrz wciąż wygląda zdrowo. Nazwa instancji może też wskazywać na plik, którego nigdy nie edytowałeś, co zdarza się na hostach uruchamiających dwa profile obok siebie.

Przechwyć pakiet zewnętrzny, nie tunel

Filtruj na interfejsie fizycznym i prawdziwym porcie, podstawiając własny interfejs: tcpdump -ni eth0 udp port 1194. Pakiety wychodzące, na które nic nie wraca, wskazują na to, co siedzi wyżej: filtrowanie dostawcy, urządzenie NAT albo zdalny adres, który nie jest tym, co myślisz. Cisza w obu kierunkach wskazuje na routing klienta lub lokalną zaporę. Odpowiedzi przychodzące bez postępu tunelu wskazują na kanał sterowania, czyli niezgodność klucza lub szyfru, a nie na filtrowanie.

Przechwyć oba kierunki i trzymaj plik krótko. Długie przechwycenie zakopuje ciekawe trzy sekundy, a odpowiedź prawie zawsze leży w pierwszej wymianie.

Najpierw liczniki, ślad tylko wtedy, gdy kłamią

Zacznij od liczników, bo nic nie kosztują. Albo nft list ruleset, albo iptables -L -n -v odpowiada na jedyne pytanie, które tu ma znaczenie: czy reguła pasowała? Kolejność rozstrzyga wynik, bo pierwsze trafienie wygrywa, dlatego szeroki DROP przed późniejszym ACCEPT zostawia ten ACCEPT martwym i dlatego dodanie reguły tak rzadko coś naprawia.

Własność też potyka ludzi. Jądro przypisuje pakiety wygenerowane lokalnie procesowi, który otworzył gniazdo, a OpenVPN zwykle działa jako root, więc reguła powiązana ze zwykłym ID użytkownika nigdy nie widzi ruchu samego tunelu. Sprawdź UID właściciela, zanim uznasz, że reguła jest błędna.

Dopiero gdy liczniki pozostają niejednoznaczne, log jest wart hałasu, i to tylko dla wąskiego wycinka: reguła iptables, która ogranicza szybkość i dodaje prefiks do swoich linii, albo reguła nftables z meta nftrace set 1, gdy działa nft monitor trace. Ślad nazywa łańcuch i regułę, która przyjęła lub odrzuciła pakiet. Potem usuń oba i trzymaj logowanie ładunku z boku.

Sprawdź też transport. Usługa zapory ograniczona do TCP nic nie mówi o nasłuchu UDP na tym numerze, więc poprawnie odczytana reguła nadal może odrzucić każdy pakiet.

Routing i droga powrotna

Przyjęty pakiet, który mimo to znika, wymaga zbadania jego ścieżki docelowej. ip route get raportuje trasę wybraną dla jednego adresu, a filtrowanie trasy odwrotnej może odrzucić odpowiedź nadchodzącą przez interfejs, którego tabela główna nigdy by nie wybrała. Objaw wygląda dokładnie jak odrzucenie przez zaporę, dlatego ta kontrola przychodzi przed kolejną regułą NAT.

Na bramie sprawdź przekazywanie i łańcuch forward zamiast łańcucha input. Potem potwierdź, że zdalna strona wie, jak dotrzeć do adresu źródłowego, bo działająca ścieżka wychodząca, na którą nic nie wraca, to cisza w obu przypadkach.

Co musi powiedzieć notatka

Dla każdej zmiany zapisz przetestowany etap, przeczytany dowód i wartość licznika po obu jego stronach. To ta notatka czyni "teraz działa" zdolnym przetrwać następny przegląd.

Dwa skróty utrzymują notatkę uczciwą. Pakiet, który nigdy nie opuścił hosta, nie mógł zostać odrzucony przez regułę gdzie indziej, jakkolwiek przekonująco wygląda konfiguracja zdalnej strony. Pakiet, który wyszedł i wrócił, przenosi pytanie ponad warstwę sieciową, gdzie liczniki zapory nie mają już nic do powiedzenia.

Powiązane artykuły