SNAT, DNAT i Masquerade: co robi każda reguła NAT w VPN

Ustaw przechwytywanie po obu stronach bramy VPN, a jeden przepływ może pokazać cztery różne adresy. NAT źródła przepisuje, skąd pakiet twierdzi, że przychodzi; NAT docelowy przepisuje, dokąd zmierza. Masquerade to nie trzeci kierunek, to reguła NAT źródła, która bierze adres z interfejsu wychodzącego zamiast stałej wartości. Nazwij, której z trzech naprawdę potrzebujesz, a większość zgłoszeń „VPN jest zepsuty” sprowadza się do pytania o drogę powrotną.

Co przepisuje każda reguła

NAT źródła, zwykle zapisywany SNAT, zmienia adres źródłowy przepływu, gdy opuszcza router lub bramę. Usługa odbierająca odpowiada na przetłumaczony adres, a urządzenie tłumaczące odwraca zmianę, korzystając ze stanu, który trzymało dla tego połączenia. W Linuksie ten stan żyje w conntrack, dlatego conntrack -L wypisuje pary oryginalną i odpowiedzi obok siebie.

NAT docelowy, DNAT, zmienia zamiast tego cel. Pakiet zaadresowany do publicznego adresu na UDP 51820 można przepisać na wewnętrzny serwer WireGuard pod 10.8.0.2:51820. Tak router domowy lub balanser w chmurze publikuje nasłuch VPN, a to nie mówi nic o tym, co tunel może nieść później.

Masquerade należy do rodziny SNAT. Reguła nie wymienia żadnego adresu; używa tego, który ma interfejs wychodzący w chwili opuszczania pakietu. Linux daje jej własny cel i jest to zwykły wybór na interfejsie WAN, który bierze adres z DHCP lub PPPoE.

Gdzie żyje mapowanie, tam rozstrzyga się awaria

Zapisuj parę na każdej granicy: przed tunelem, w nim i na interfejsie publicznym. Przechwycenie wewnątrz tunelu legalnie różni się od tego na zewnątrz, a kto porównuje oba bez wiedzy, gdzie odbywa się tłumaczenie, będzie ścigał niewłaściwy host.

Ruch powrotny musi przechodzić przez urządzenie, które trzyma mapowanie. Jeśli odpowiedź wybierze inną trasę, drugi link nadrzędny, trasę polityki lub dostawcę, który nigdy nie słyszał o twoim zakresie prywatnym, stanowe tłumaczenie odwrotne nigdy nie następuje, a klient widzi ruch jednokierunkowy. Dodawanie kolejnego NAT źródła rzadko naprawia brakującą trasę powrotną; może ukryć objaw na jednym przepływie, psując politykę opartą na adresach wszędzie indziej.

Innym częstym błędem jest oczekiwanie, że tunel stworzy trasowalność. Prywatny klient, którego pakiety wychodzą do internetu, potrzebuje prawidłowego wyjścia: trasy domyślnej, bramy przekazującej dalej i zwykle tłumaczenia źródła na adres publiczny. Samo szyfrowanie nie czyni adresu prywatnego osiągalnym.

Masquerade czy jawny SNAT

Porównaj je po tym, co obiecują. Masquerade wybiera adres wyjściowy, jawny SNAT go przypina. Na bramie ze stabilnym adresem publicznym przypięcie daje logom i listom dozwolonych partnerów jedną przewidywalną wartość. Na łączu WAN dynamicznym przypięty adres SNAT staje się błędny w chwili zmiany dzierżawy, i właśnie dla tego przypadku powstał Masquerade.

Zakres liczy się tak samo jak wybór. Reguła Masquerade dopasowująca każdy pakiet opuszczający bramę, bez ograniczenia źródła czy celu, tłumaczy też ruch, który chciałeś zostawić nietknięty, w tym ruch do innych sieci prywatnych. Ogranicz regułę do zakresu klientów, zamierzonego celu i interfejsu.

Przy IPsec opartym na politykach to boli najbardziej. Przewodnik strongSwan po przekazywaniu przechodzi przez włączanie przekazywania IP i dodawanie reguły SNAT źródła dla klientów, a ta sama dokumentacja obejmuje wyłączanie ruchu, który musi zachować pierwotny adres. Przetłumacz źródło, zanim dopasuje je polityka bezpieczeństwa, a tunel może wstać, podczas gdy ruch nadal pada, bo pakiet nie wygląda już jak wynegocjowany selektor.

Zdecyduj też, co ma zobaczyć drugi koniec. Po tłumaczeniu usługa widzi bramę, nie pojedynczego klienta. Upraszcza to routing powrotny, a jednocześnie spłaszcza logi i niweczy listy dozwolonych dla poszczególnych klientów. Jeśli zachowanie adresów klientów ma znaczenie, zaplanuj trasowaną drogę powrotną zamiast ukrywać je, żeby test przeszedł.

Czytanie reguł na bramie Linux

Brama dostępu zdalnego z klientami w 10.8.0.0/24 i interfejsem WAN o nazwie eth0 potrzebuje włączonego przekazywania i polityki filtrowania, która pozwala na przepływ, zanim jakakolwiek reguła NAT pomoże. Wersja iptables trzyma oba kierunki w tabeli nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

Forma nftables używa tych samych dwóch haczyków z nazwanym interfejsem i jawnym łańcuchem:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Oba fragmenty zakładają, że łańcuch filtrowania już akceptuje przekazywany przepływ. NAT nie jest regułą zezwolenia, a poprawnie przetłumaczony pakiet nadal może zostać odrzucony jedną tabelę dalej. Potwierdź żywe mapowanie za pomocą conntrack -L, potwierdź, co jest wczytane, za pomocą nft list ruleset lub iptables-save -t nat, a następnie przechwyć na obu interfejsach, żeby zobaczyć, że adres naprawdę się zmienia.

Tryby awarii wyglądające jak zła reguła

Ruch typu spinki do włosów to klasyka. Klient wewnętrzny, który dociera do wewnętrznego serwera przez jego publiczny adres, potrzebuje DNAT na wejściu i tłumaczenia źródła na wyjściu powrotnym, inaczej serwer odpowiada prosto do klienta i odpowiedź jest odrzucana. Poprawką jest druga, węższa reguła dla tego przypadku wewnętrzne-do-publicznego, a nie szersza reguła Masquerade dla wszystkiego.

Podwójne tłumaczenie jest tym cichym. Klient, który już jest za NAT klasy operatorskiej, trafia na bramę z adresem, którego nie da się wytresować z powrotem, więc tłumaczysz ponownie. To działa, ale logi noszą teraz dwa skoki prywatnego adresowania i każde śledztwo potrzebuje obu mapowań. IPsec oparty na politykach dokłada trzecie skrzywienie: przetłumacz przed dopasowaniem polityki i dostajesz SA, które stoi, choć ruch nie przechodzi, co czyta się jak błąd zapory ogniowej, a nie NAT.

Jest też test, który przechodzi, i wdrożenie, które zawodzi. Ręczne uruchomienie polecenia NAT dowodzi mechanizmu, nie konfiguracji. Reguła dodana w czasie działania znika po restarcie lub przy następnym zdarzeniu interfejsu, a reguła Masquerade związana z interfejsem, który zmienia numer, może po cichu zmienić adres widziany przez drugi koniec. Wstaw regułę do konfiguracji zapory, która ją posiada, i przetestuj ponownie po ponownym połączeniu.

Lista kontrolna przed zapisaniem reguły

Najpierw nazwij kierunek: źródło, cel albo oba. Potem ustal, kto musi trzymać stan — brama, router wyżej czy partner IPsec — i potwierdź, że droga odpowiedzi wraca przez niego. Ogranicz regułę do zakresu klientów, celu i interfejsu, które naprawdę masz na myśli, i zdecyduj z góry, czy drugi koniec ma widzieć bramę, czy pierwotny adres klienta.

Testuj z klienta, nie z bramy. Przeglądarka na samej bramie może całkowicie ominąć regułę tłumaczenia dla klientów, więc działająca tam strona niczego nie dowodzi o tunelu. Wyślij jedno żądanie pochodzące od klienta, obserwuj liczniki i tabelę conntrack, i powtórz po ponownym połączeniu tunelu oraz zmianie adresu WAN, jeśli którekolwiek z nich jest możliwe tam, gdzie pracujesz.