ufw allow 443 nic nie dało usłudze za VPN-em

Ping przechodzi z klienta VPN, usługa TCP kończy się przekroczeniem czasu, a ufw allow 443/tcp nie zmienia absolutnie niczego. Gdy aplikacja działa na hoście za bramą, a nie na samej bramie, to zezwolenie zostało zapisane dla niewłaściwej ścieżki ruchu. Pakiet nie jest zaadresowany do zapory i nie jest dostarczany do procesu lokalnego, więc reguły wejściowe nigdy go nie widzą. Poprawką jest reguła trasy skierowana na przekazywany przepływ, a dowód na to już jest w dzienniku.

Zdecyduj, czy cel jest lokalny, czy przekazywany

Czytaj pakiet tak, jak widzi go jądro. Ruch dostarczany do usługi na bramie jest wejściem lokalnym. Ruch, który brama kieruje dalej do innego hosta, jest przekazywany, a UFW utrzymuje osobne zestawy reguł dla obu ścieżek. Różnicę rozstrzyga adres docelowy i wyszukanie trasy, a nie interfejs, na którym pakiet dotarł.

Wiersz dziennika pokazujący ten sam interfejs w obu polach IN i OUT nadal może opisywać pakiet rutowany, ponieważ tunel, który przenosi klientów do i z jednego urządzenia, wygląda dokładnie tak. Adres docelowy rozstrzyga tę kwestię szybciej niż nazwy interfejsów. Dwukrotne zobaczenie tej samej nazwy nie dowodzi dostarczenia lokalnego, a wymyślanie interfejsu tunelu, którego wdrożenie nigdy nie utworzyło, też nie pomaga.

Przeczytaj blok, zanim dodasz jakąkolwiek regułę

Odtwórz jedną autoryzowaną próbę połączenia i zapisz jej źródło, cel, protokół oraz port docelowy tak, jak zapisała je brama. Porównaj te cztery wartości z wpisem w dzienniku i z rzeczywistym położeniem usługi. Wcześniejszy udany ping dowodzi tylko, że dozwolona była jego własna wymiana, a zapora może obsłużyć TCP SYN do aplikacji zupełnie inaczej.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

Pierwsze polecenie zwraca wyrok wraz z jego polami, a drugie pokazuje, co jest już wczytane i w jakiej kolejności. Przeczytaj oba, zanim cokolwiek edytujesz, bo wcześniejsze odrzucenie powyżej twojej reguły wyjaśnia ten sam objaw bez żadnej brakującej reguły.

Napisz najwęższą pasującą regułę trasy

W tym przykładzie klienci przychodzą na tun0 z 172.20.8.0/24, usługa nasłuchuje na 10.30.0.15 na porcie 8443, a brama wychodzi przez ens5. Te wartości wybrano tak, aby w ogóle nie przypominały domyślnej wartości chmurowego VPC 10.0.0.0/16 ani sieci domowej 192.168.0.0/16, a 8443 trzyma przykład z dala od własnego nasłuchu 443 bramy.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

Przebieg próbny wypisuje zestaw reguł, który by powstał, i to najtańszy sposób, aby zobaczyć, czy twoja reguła trafia przed istniejące odrzucenie, czy po nim. Sprawdź nazwy interfejsów i adresy wewnętrzne wobec wdrożenia, a nie wobec przykładu, i pamiętaj, że gdy translacja adresu docelowego działa pierwsza, filtr widzi już przetłumaczony cel.

Utrzymaj ścieżkę powrotną ze stanem

UFW śledzi dozwolone połączenia, więc odpowiedzi na dozwolony przekazywany przepływ są wpuszczane bez jawnej reguły odwrotnej. Dodanie nieograniczonej reguły w przeciwnym kierunku, żeby wszystko działało, rozszerza politykę daleko poza jedną usługę i nie jest potrzebne do normalnej wymiany żądania i odpowiedzi. Utrzymaj ścieżkę powrotną domyślną, a zestaw reguł czytelny.

Zastosuj regułę dopiero gdy przebieg próbny odpowiada twojemu zamiarowi, a potem potwierdź, że uporządkowana lista pokazuje ją w oczekiwanym miejscu. Zachowaj nasłuch VPN i reguły zarządzania jako odrębne sprawy, bo ich zmiana to inna decyzja niż wpuszczenie jednej aplikacji. Zanotuj zmianę tam, gdzie zapisana jest topologia, aby następny inżynier nie musiał odkrywać jej ponownie ze zrzutu pakietów.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Sprawdź, czego UFW nie może wymusić za ciebie

Poprawna reguła nadal wymaga przekazywania w jądrze i trasy, która dociera do usługi. Potwierdź oba, zanim po raz drugi obwinisz zaporę.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Potem spójrz poza host. Na instancji w chmurze polityka UFW gościa nie zastępuje grup bezpieczeństwa, ACL podsieci ani własnej konfiguracji przekazywania dostawcy, więc lokalna blokada jest dowodem o jednej warstwie, a nie dowodem, że wszystkie pozostałe warstwy przepuszczają usługę.

Zakończ testem nowego połączenia przy włączonej zaporze, z dozwolonego źródła i z niepowiązanego. Wyłączenie UFW usuwa objaw i niszczy dowód w tym samym poleceniu, dlatego powinno to być ostatnie doświadczenie, a nie pierwsze.