Gdzie trafia NAT VPN w before.rules UFW i jak to testować

Reguła NAT, która działa wpisana w powłoce, zawodzi po wklejeniu do before.rules, ponieważ ten plik nie jest skryptem. To dokument w formacie przywracania z sekcjami tabel, deklaracjami łańcuchów i znacznikiem COMMIT dla każdej tabeli. Linia w złym miejscu albo przerywa całe przywracanie, albo po cichu odrzuca reguły, o których myślałeś, że istnieją. Poniższa procedura umieszcza fragment tam, gdzie oczekuje go framework, i dowodzi wyniku przed następnym przeładowaniem.

Polecenie powłoki nie jest plikiem przywracania

Linia zaczynająca się od iptables -t nat jest poleceniem dla binarnego iptables, natomiast plik czytany przez UFW jest opisem pełnego zestawu reguł. Różnica nie jest kosmetyczna: format przywracania musi wiedzieć, w której tabeli się znajduje, jakie łańcuchy istnieją i gdzie tabela się kończy. Polecenie wklejone do tego dokumentu jest albo błędem składni, albo, co gorsza, regułą przypiętą do niewłaściwej tabeli. Framework ładuje te pliki przez narzędzia przywracania właśnie dlatego, że są deklaratywne, a nie sekwencyjne.

Dokument jest też ładowany jako całość, więc jedna wadliwa sekcja może zatrzymać stosowanie reszty pliku. Dlatego mały błąd we fragmencie NAT pociąga za sobą także reguły filtrowania, i tak zmiana firewalla staje się awarią.

Umieść fragment w istniejącej sekcji tabeli

Fragment NAT ma kształt, a kształt jest ważniejszy niż tekst reguły w środku. Nagłówek tabeli otwiera sekcję, deklaracje łańcuchów ustawiają liczniki, reguły następują, a COMMIT zamyka sekcję.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Pula i interfejs powyżej to placeholdery dla Twoich wartości; struktura jest tą częścią, którą warto skopiować. Jeśli plik już zawiera sekcję *nat, dodaj regułę wewnątrz niej, zamiast otwierać drugą, ponieważ format oczekuje jednego COMMIT na tabelę, a dwie sekcje dla tej samej tabeli to naprawa czekająca na zdarzenie. Zachowaj definicje łańcuchów dystrybucji nietknięte, łącznie z tymi, które dostawca dodał dla własnej integracji. Podręcznik frameworka UFW dokumentuje pliki before, user i after wraz z wymogiem pasującego COMMIT.

Jeśli plik okaże się pusty, nie wypełniaj go z poradnika. Potwierdź, który pakiet go posiada i jaka jest faktycznie aktywna polityka, ponieważ pusty trwały plik nie dowodzi, że jądro nie ma reguł, a wczytany zestaw reguł nie dowodzi, że następne przeładowanie będzie miało pełny plik do odczytu. Najpierw przywróć obsługiwaną linię bazową, a potem ponownie zastosuj na niej zmiany witryny.

Przetestuj kandydata bez jego stosowania

Narzędzie przywracania potrafi przeanalizować i zbudować zestaw reguł bez stosowania go, i to najtańszy dostępny test. Uruchom je na chronionej kopii, a nie na aktywnym pliku, i czytaj tekst błędu, a nie tylko status wyjścia. Błąd analizy wskazuje linię i zwykle tabelę, co jest czymś więcej, niż powie Ci nieudane przeładowanie.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Przejście tego sprawdzenia dowodzi, że dokument się analizuje, i nic więcej. Nie dowodzi, że kandydat nadal zawiera każdy łańcuch, od którego zależy UFW, że zezwala tylko na zamierzone źródła ani że administracja zdalna pozostaje osiągalna. To osobne przeglądy, a ostatni zasługuje na drugą sesję otwartą przed rozpoczęciem.

Wybierz narzędzie pasujące do zainstalowanego backendu i rodziny adresów. Host uruchamiający backend nft przez warstwę zgodności potrzebuje odpowiedniego polecenia, a reguły IPv6 żyją w zupełnie innym pliku.

Trzymaj przekazywanie, NAT i politykę dostępu osobno

Tłumaczenie źródła rozwiązuje problem adresowania i nic nie daje. Przekazywanie to osobne uprawnienie kontrolowane przez sysctl i przez tabelę filtrowania, i to właśnie ono bywa zapominane, gdy tunel trasuje, ale nie przepuszcza ruchu. Polityka dostępu to trzecia decyzja o tym, które źródła mogą dotrzeć do których usług, i żadna reguła NAT jej nie wyraża. Właśnie rozdzielenie tych trzech czyni awarię diagnozowalną zamiast jednego mglistego objawu.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Czytaj te trzy wyniki razem, a nie jeden po drugim. Reguła masquerade z wyłączonym przekazywaniem daje klienta, który się łączy i do niczego nie dociera, co z perspektywy klienta wygląda dokładnie jak błąd routingu i kieruje ludzi do niewłaściwego pliku. Tabela filtrowania jest też miejscem, w którym ukrywa się zbyt szeroki accept, więc sprawdź tam jej domyślną politykę.

Sprawdź przeładowanie, odmowę i utratę VPN

Trzy obserwacje składają się na pełny test akceptacyjny: przeładowanie się udaje, dozwolona operacja klienta działa, a żądanie, które powinno zostać odrzucone, faktycznie jest odrzucane. Trzecia jest pomijana, i to jedyny dowód, że polityka cokolwiek robi.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Następnie przetestuj awarię, dla której projektowałeś. Zestrzel tunel i obserwuj, co robi host, ponieważ polityka działająca tylko przy włączonym VPN to polityka z niewypowiedzianą zależnością. Przeładuj jeszcze raz potem, aby dowodzić, że to plik, a nie jakiś pozostały stan wykonania, daje działający wynik.

NAT IPv4 nic nie mówi o IPv6, więc podaj zamierzone pokrycie obu rodzin w tej samej notatce co reguła. Celem jest spójna zarządzana polityka, a fragment, który przypadkiem się przeanalizował, nie jest jej dowodem.