Tunel wstaje, dziennik mówi połączono, a jedna aplikacja nadal do niczego nie dociera. Na kliencie Linux oznacza to zwykle, że zapora dystrybucji filtruje ścieżkę, którą klient VPN nigdy nie zarządzał. Dwa menedżery mogą być aktywne jednocześnie, każdy z własnym wyobrażeniem o interfejsie, strefie i kierunku ruchu. Ustalenie właściciela przed jakąkolwiek zmianą jest szybsze niż próbowanie reguł, aż coś zacznie działać.

Znajdź menedżer i backend

Zacznij od tego, co jest faktycznie wczytane, a nie od tego, co jest zainstalowane. Dystrybucja może dostarczać firewalld, ufw i zwykłą usługę nftables, a tylko jedna z nich włada działającym zestawem reguł. Pakiety spokojnie współistnieją, a reguła wprowadzona przez niewłaściwy frontend nigdy nie dociera do jądra. Odczytaj aktywną usługę, a potem odczytaj zestaw reguł, który utworzyła.

Backend jest równie ważny jak frontend. Instalacja firewalld może sterować nftables lub starym backendem iptables w zależności od wersji i konfiguracji, a oba dają inny wynik inspekcji. Zapisz dystrybucję, wersję i backend w zgłoszeniu, zanim porównasz swój system z jakimkolwiek przewodnikiem.

Dopasuj kierunek i interfejs

Wychodzące żądanie klienta, przychodzący nasłuch i przekazywany pakiet przechodzą przez różne haki, a reguła dla jednego nie obejmuje pozostałych. Strefa, która dopuszcza lokalny LAN, często nie zawiera interfejsu tunelu ani puli adresów VPN. Interfejs tunelu zwykle trafia do strefy domyślnej, która bywa surowsza niż strefa karty fizycznej. Ta niezgodność wyjaśnia, dlaczego przeglądanie działa w LAN i zatrzymuje się w chwili, gdy tunel wstaje.

Zapytaj, który kierunek zawiódł, zanim wybierzesz regułę. Aplikacja, która nie może połączyć się na zewnątrz, potrzebuje ścieżki wyjściowej, a usługa przychodząca potrzebuje ścieżki wejściowej na interfejsie tunelu. Dodanie reguły do niewłaściwego łańcucha daje zmianę, która wygląda na zastosowaną i nie robi zupełnie nic.

Utrzymuj właścicieli reguł w zgodzie

Hak klienta VPN, środowisko uruchomieniowe kontenerów i usługa dystrybucji mogą zmieniać sieć, i nie koordynują się wzajemnie. Reguły wpisane ręcznie znikają przy następnym przeładowaniu, a reguły wstawione do łańcucha menedżera mogą być oceniane w kolejności, której nie zamierzałeś. Używaj trwałej konfiguracji menedżera i sprawdzaj wynikowy zestaw reguł, a nie plik, który napisałeś. Wyłączanie całej zapory, bo jedna usługa jest nieosiągalna, zamienia mały problem na duży.

Wąskie liczniki to tani sposób na znalezienie odrzuconego przepływu. Reguła rejestrowania ograniczona do jednego celu i jednego portu pokazuje, czy odrzucenie następuje lokalnie, bez przechwytywania cudzego ruchu. Usuń regułę rejestrowania po zakończeniu dochodzenia, bo to diagnostyka, a nie polityka, i dokumentacja stref firewalld wyjaśnia, jak łączą się interfejsy i usługi.

Sprawdź poprawkę bez utraty blokady

Sprawdź zastosowany stan menedżerem, który nim zarządza, używając poleceń zgodnych z zarejestrowanym backendem. Poniższa lista zakłada, że odpowiada firewalld; zastąp ją odpowiednikiem dla nftables lub ufw, zamiast uruchamiać wszystkie. Mieszanie narzędzi w jednej sesji to sposób, w jaki maszyna kończy z dwoma sprzecznymi zestawami reguł.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

Pierwsze polecenie nazywa strefy i przypisane do nich interfejsy, co pokazuje, gdzie tunel faktycznie trafił. Drugie wypisuje reguły i usługi strefy, więc widać, czy interfejs VPN jest w ogóle objęty. Lista nftables jest podstawową prawdą o używanym backendzie, a reguła istniejąca tylko w pliku konfiguracyjnym nie pojawia się tam. Porównaj trzy wyniki z dodaną regułą, a niezgodność zwykle sama się nazywa.

Potem powtórz pierwotne żądanie i wymagane zachowanie przy awarii. Nowo działająca witryna nie wystarczy, jeśli ta sama zmiana usunęła blokadę klienta, więc przetestuj też niezabezpieczoną ścieżkę. Zanotuj menedżer, backend, interfejs i cel reguły, bo aktualizacja pakietu, która ożywi drugi menedżer, inaczej odbuduje cały bałagan.

Powiązane artykuły