NAT na Sophos Firewall: SNAT, DNAT, MASQ i PAT

NAT zmienia adresy lub porty pakietu. Nie decyduje jednak o tym, czy połączenie jest dozwolone, ani nie tworzy trasy. Aby przepływ danych działał prawidłowo, reguła NAT, reguła zapory, routing i ścieżka powrotna muszą być ze sobą zgodne.

Dlatego najlepiej zacząć nie od pytania „Jakiego typu NAT potrzebuję?”, lecz od ustalenia: Który adres lub port ma się zmienić między wejściem a wyjściem? Jeśli nie ma jednoznacznej odpowiedzi, rozwiązania należy zwykle szukać w routingu lub regule zapory, a nie w NAT.

⚠️ Reguła NAT nie zezwala na ruch. Jeśli reguła zapory zezwala na ruch, ale żadna reguła NAT nie jest dopasowana, SFOS przekazuje pakiet bez translacji. Jeśli brakuje odpowiedniej reguły zapory, pakiet zostaje odrzucony i zarejestrowany w dzienniku.

Do jakich zadań służy NAT?

• Klienci w sieci LAN mają uzyskać dostęp do internetu: zazwyczaj SNAT z MASQ.
• Usługa wewnętrzna ma być dostępna pod adresem publicznym: DNAT; w przypadku HTTP/HTTPS najpierw sprawdź WAF.
• Port zewnętrzny różni się od wewnętrznego: translacja usługi za pomocą Translated service (PAT).
• Klienci wewnętrzni używają publicznej nazwy serwera wewnętrznego: preferuj split DNS albo zastosuj odpowiednio skonfigurowaną Loopback Rule.
• Niepokrywające się sieci komunikują się przez VPN site-to-site: zazwyczaj wystarczą routing i reguły zapory bez NAT.
• Sieci nakładają się na siebie: zaplanuj NAT stosownie do typu VPN; nie stosuj doraźnie ogólnej reguły MASQ.
• Trzeba tylko zezwolić na dostęp lub go zablokować: zmień regułę zapory, nie twórz reguły NAT.

Procedurę publikowania serwera przedstawiono w artykule Publikowanie serwera przez DNAT na Sophos Firewall, który opisuje kreator, regułę ręczną, zabezpieczenia, uruchomienie produkcyjne i wycofanie zmiany. Ten artykuł wyjaśnia model NAT, aby ułatwić interpretowanie takich reguł i diagnozowanie błędów.

Inne ściśle powiązane przypadki szczególne opisano w artykułach NAT64 z Direct Web Proxy, Proxy ARP dla dodatkowych publicznych adresów IPv4 oraz NAT podczas diagnozowania problemów z IPsec.

Prawidłowa interpretacja pól Original i Translated

W sekcji Rules and policies > NAT rules > Add NAT rule pole Original opisuje pakiet w postaci, w której dociera on do zapory. Pole Translated określa zmianę wprowadzaną przez SFOS.

Reguła jest wybierana na podstawie następujących pól:

• Original source
• Original destination
• Original service
• Inbound interface
• Outbound interface

Pola Translated source (SNAT), Translated destination (DNAT) i Translated service (PAT) określają wynik translacji, a nie dodatkowe kryteria dopasowania. Reguły NAT są oceniane od góry do dołu; stosowana jest pierwsza dopasowana reguła.

Reguły NAT są dostępne dla IPv4 i IPv6. Przed utworzeniem reguły wybierz właściwą rodzinę adresów w Rules and policies > NAT rules; przykładowe adresy IPv4 nie nadają się do reguły IPv6. Add NAT rule > New NAT rule otwiera konfigurację ręczną. Nowe reguły są domyślnie włączone. Rule position oferuje Top i Bottom; później można zmienić kolejność przez przeciąganie. Przed Save sprawdź kryteria i pozycję, aby nowa reguła nie przejęła przypadkowo ruchu produkcyjnego.

Dwa przykłady pakietów

Klient 10.10.10.80 łączy się przez Port2 z adresem 198.51.100.20:443. Reguła SNAT może zmienić wyłącznie adres źródłowy na MASQ. Adres docelowy i usługa pozostają ustawione na Original.

Podczas publikowania usługi klient zewnętrzny łączy się z adresem 203.0.113.10:5555. DNAT zmienia adres docelowy na 172.16.16.10, a PAT zmienia usługę na 443. Reguła wygląda wtedy następująco:

• Original destination: 203.0.113.10
• Original service: TCP 5555
• Translated destination (DNAT): 172.16.16.10
• Translated service (PAT): TCP 443

PAT nie jest więc odrębnym typem translacji adresów obok SNAT i DNAT, lecz translacją portu lub usługi w ramach reguły NAT.

SNAT i MASQ dla ruchu wychodzącego

SNAT zmienia adres źródłowy. Typowa reguła LAN–WAN używa sieci wewnętrznej jako Original source, interfejsu WAN jako Outbound interface oraz MASQ jako Translated source. Adres docelowy i usługa pozostają ustawione na Original albo zostają ograniczone do rzeczywiście wymaganego zakresu.

MASQ domyślnie używa adresu interfejsu wychodzącego. W tym celu konfiguracja fabryczna zawiera regułę Default SNAT IPv4. Jeśli nie jest ona potrzebna, Sophos zaleca jej wyłączenie zamiast usunięcia: reguła może zostać utworzona ponownie podczas tworzenia lub aktualizacji interfejsu WAN.

Po migracji z SFOS 17.5 lub starszej wersji na końcu tabeli może dodatkowo pojawić się wyłączona domyślna reguła SNAT. Służy ona do zastąpienia usuniętych reguł Linked MASQ i nie należy jej mylić z aktywnie używaną regułą fabryczną.

Wielu klientów lub serwerów wewnętrznych może korzystać z tego samego publicznego adresu źródłowego: SFOS rozróżnia ich połączenia za pomocą różnych numerów portów. Takie przypisanie portów źródłowych nie jest przekierowaniem usługi DNAT do serwera.

Tworzenie niezależnej reguły SNAT LAN–WAN

Niezależna reguła SNAT może obsługiwać wiele reguł zapory. Najpierw sprawdź istniejące reguły NAT, trasę, interfejs wyjściowy i ścieżkę powrotną; zapisz poprzedni stan wraz z ID i pozycjami. Przykład zezwala tylko na HTTPS z sieci klientów do określonego celu testowego; zastąp wszystkie adresy i interfejsy własnymi wartościami.

1. Otwórz Rules and policies > NAT rules, wybierz IPv4, a następnie Add NAT rule > New NAT rule. Ustaw Rule name, na przykład LAN-Web-Standalone-MASQ. W Rule position wybierz Top lub Bottom, a następnie świadomie przeciągnij regułę nad bardziej ogólne pasujące reguły; nie umieszczaj jej bezrefleksyjnie na początku.
2. Ustaw Original source na Clients_LAN (10.10.10.0/24), Original destination na obiekt hosta dla 198.51.100.20, a Original service na HTTPS. Adres dokumentacyjny nie jest rzeczywistym serwerem testowym. Dla ogólnego dostępu do internetu można świadomie rozszerzyć zakres celu; usługi nadal ogranicz do niezbędnych.
3. Ustaw Translated source (SNAT) na MASQ, a Translated destination (DNAT) i Translated service (PAT) na Original. Wybierz rzeczywisty interfejs LAN w Inbound interface, w przykładzie Port2, oraz WAN w Outbound interface, tutaj Port1. Wybierz Save i zanotuj NAT Rule ID.
4. W Rules and policies > Firewall rules wybierz IPv4 > Add firewall rule > New firewall rule, jeśli brakuje odpowiedniej reguły zezwalającej. Ustaw nazwę i pozycję, Action Accept, Source zones LAN, Source networks and devices Clients_LAN, Destination zones WAN, Destination networks na ten sam cel oraz Services HTTPS. Skonfiguruj odpowiednie zabezpieczenia i Log firewall traffic, następnie Save. Nie twórz kolejnej Linked NAT Rule.
5. Nawiąż nowe połączenie HTTPS z własnym celem testowym i zakończ je normalnie. Porównaj oba Rule IDs w Log Viewer; Packet capture powinien pokazać oczekiwany źródłowy adres WAN na wyjściu. Przy błędnym dopasowaniu NAT najpierw sprawdź wyższe reguły; przy braku odpowiedzi routing i powrót. Aby wycofać zmianę, wyłącz tylko dodane reguły i przywróć zmienione pozycje; nie usuwaj współdzielonej reguły zezwalającej. Sprawdź poprzedni stan w nowej sesji.

Tworzenie reguły LAN–WAN z powiązanym NAT

Aby zezwolić na ściśle określony ruch IPv4, można powiązać SNAT podczas tworzenia reguły zapory. Najpierw sprawdź, czy istniejąca reguła SNAT już tłumaczy przepływ zgodnie z potrzebami; jeśli tak, dodatkowa Linked NAT Rule nie jest potrzebna. Trasa i ścieżka powrotna muszą być prawidłowe niezależnie od NAT.

1. Otwórz Rules and policies > Firewall rules, wybierz IPv4 i utwórz regułę przez Add firewall rule > New firewall rule. Wybierz czytelną nazwę, na przykład LAN-Web-Out, oraz odpowiednią pozycję; ustaw Action na Accept i włącz Log firewall traffic.
2. Ustaw Source zones na LAN i ogranicz Source networks and devices do sieci klientów, która wymaga dostępu. Przykładem jest obiekt sieciowy Clients_LAN dla 10.10.10.0/24; dostosuj nazwę i podsieć do własnego środowiska. Ustaw Destination zones na WAN. W Destination networks wybierz wymagane cele, a w Services tylko niezbędne usługi, na przykład HTTPS dla tego przepływu WWW. Any nie jest ogólnym wymogiem. DNS i pozostałe potrzebne usługi należy uwzględnić osobno.
3. Wybierz Create linked NAT rule. Nadaj regule NAT odrębną nazwę, na przykład LAN-Web-MASQ, i odpowiednią pozycję. Ustaw Translated source (SNAT) na MASQ: ten przepływ ma używać adresu rzeczywistego interfejsu wyjściowego, a reguła zapory nadal ogranicza źródła, cele i usługi.
4. Najpierw wybierz Save w konfiguracji powiązanego NAT, a następnie ponownie Save, aby zapisać regułę zapory. Zapisanie samego zagnieżdżonego okna NAT nie kończy procedury.
5. Sprawdź regułę zapory w Firewall rules i powiązaną regułę SNAT w NAT rules; zanotuj obie pozycje i ich Rule IDs. Osobno sprawdź kolejność w każdej tabeli. Dopasowana reguła NAT umieszczona wyżej może mieć pierwszeństwo; powiązanie nie gwarantuje priorytetu.
6. Z klienta objętego regułą nawiąż rzeczywiście nowe połączenie z dozwolonym celem i usługą, a następnie zakończ połączenie testowe w zwykły sposób, aby mógł powstać wpis sesji w dzienniku. Przefiltruj ten przepływ w Log Viewer i porównaj Firewall Rule ID oraz NAT Rule ID z zanotowanymi identyfikatorami. Jeśli identyfikator zapory jest błędny, najpierw sprawdź kryteria i kolejność reguł zapory; jeśli błędny jest identyfikator NAT, zacznij od wyżej położonych reguł NAT. Sama obecność obu wpisów nie potwierdza działającego dostępu do internetu.

Ważne ograniczenia SNAT

Oprócz MASQ pole Translated source (SNAT) może wskazywać pojedynczy IP lub zakres IP. Opis SFOS 22 wyraźnie dopuszcza dowolny IP przypisany do interfejsu jako źródło i podaje Add do tworzenia obiektu IP/zakresu. Opis typów NAT w SFOS 23 nadal wymienia pojedyncze IP i zakresy; pominięcie tych zdań w opisie Add nie oznacza usunięcia obsługi. Stały adres musi być osiągalny w danym środowisku i zgodny z oczekiwaną ścieżką powrotną.

• Zakres w polu Translated source nie tworzy stałego odwzorowania jeden do jednego. SFOS używa kolejnego wolnego adresu z zakresu.
• Interfejs publiczny należący do mostu nie może pełnić funkcji interfejsu Source NAT. Jeśli używany interfejs zostanie później dodany do mostu, SFOS usunie powiązane reguły SNAT.
• Opcja Override source translation for specific outbound interfaces umożliwia użycie różnych przetłumaczonych źródeł dla poszczególnych interfejsów wychodzących w jednej regule SNAT. Kolejne przypisania dodaje się za pomocą opcji Expand.
• W sieciach VPN route-based z wartością Any dla podsieci lokalnych i zdalnych albo z konfiguracją dual-IP funkcja MASQ może używać adresu XFRM jako źródła wewnętrznego. Adres WAN pozostaje widoczny w zewnętrznym nagłówku tunelu.

Przed zmianą konfiguracji mostu lub produkcyjnych pul SNAT należy więc udokumentować odpowiednie reguły, a następnie przetestować je przy użyciu rzeczywiście nowego przepływu ruchu.

DNAT, PAT, Loopback i Reflexive Rules

DNAT zmienia adres docelowy. PAT zmienia dodatkowo usługę lub port, do którego kierowane jest połączenie. Protokół musi pozostać taki sam: port TCP można przetłumaczyć na inny port TCP, a port UDP na inny port UDP, ale nie można przetłumaczyć TCP na UDP.

Jeśli wybrano kilka usług Original lub Any, Translated service (PAT) musi mieć wartość Original. Jednoznaczne przekierowanie używa jednej konkretnej usługi pierwotnej i jednej przetłumaczonej. Translated destination (DNAT) może być adresem IP lub FQDN. Translacja usług obsługuje pojedynczy port docelowy albo taką samą liczbę portów pierwotnych i przetłumaczonych: na przykład wiele portów jednej usługi pierwotnej na jeden port (many-to-one) lub zbiory portów o tej samej wielkości (many-to-many). Many-to-many wymaga równej liczby portów; kilka osobno wybranych usług pierwotnych nie pozwala na translację PAT. Protokół musi zawsze pozostać ten sam.

Reguła zapory odpowiadająca DNAT

Dla ruchu przychodzącego SFOS najpierw ustala pasującą regułę DNAT. Następnie ocenia regułę zapory. Obowiązuje przy tym nietypowe, ale ważne przypisanie:

• Destination zone: strefa wewnętrznego adresu docelowego po DNAT, na przykład DMZ.
• Destination networks: publiczny adres docelowy przed DNAT.
• Services: bez PAT — usługa, z którą nawiązywane jest połączenie. W przypadku PAT oficjalny przykład Sophos obejmuje w regule zapory zarówno usługę pierwotną, jak i przetłumaczoną.

W kierunku przeciwnym najpierw oceniana jest reguła zapory, a następnie SFOS stosuje odpowiednią regułę SNAT.

Reguła NAT nie zastępuje tej reguły zapory. Pełną konfigurację DNAT, w tym ograniczenie źródeł, IPS, rejestrowanie i zewnętrzny test akceptacyjny, opisuje procedura DNAT.

Loopback Rule

Loopback Rule może umożliwić klientom wewnętrznym dostęp przy użyciu publicznego adresu IP lub publicznej nazwy FQDN. Split DNS jest często bardziej przejrzystym rozwiązaniem: wewnętrznie ta sama nazwa wskazuje bezpośrednio wewnętrzny adres serwera, dzięki czemu hairpin NAT nie jest potrzebny.

Server Access Assistant tworzy Loopback Rule tylko wtedy, gdy jako adres publiczny wybrano interfejs WAN zapory, a opcję External source networks and devices ustawiono na Any. Wprowadzenie publicznego adresu IP lub bardziej ograniczonego źródła zewnętrznego nie powoduje utworzenia tej automatycznej Loopback Rule.

W ręcznej konfiguracji DNAT Create loopback rule jest osobną opcją. Wyjściowa reguła DNAT musi używać Original source Any, Translated source (SNAT) MASQ oraz Translated destination (DNAT) innej niż Original. To nie są pola kreatora. Nie usuwaj ograniczenia źródeł zewnętrznych tylko po to, aby uzyskać loopback: najpierw rozważ split DNS lub osobno zaplanowaną regułę wewnętrzną. Po zapisaniu osobno przetestuj dostęp wewnętrzny i ograniczenia zewnętrzne.

Reflexive Rule

Reflexive Rule tworzy dla reguły DNAT odwrotną regułę SNAT. Odwraca kryteria dopasowania i może tłumaczyć wychodzący ruch serwera przy użyciu odpowiedniej tożsamości publicznej. Jeśli pierwotny adres docelowy nie jest adresem IP albo podlega translacji, Reflexive Rule używa MASQ jako przetłumaczonego źródła.

Podczas ręcznego tworzenia DNAT Create reflexive rule generuje tę regułę lustrzaną; Create loopback rule jest niezależna. Wygenerowane reguły używają ID i nazwy reguły wyjściowej, ale pozostają osobne. Przy wycofywaniu zidentyfikuj i wyłącz każdy wygenerowany wpis oddzielnie, a następnie sprawdź nowe połączenia wewnętrzne i zewnętrzne.

Loopback i Reflexive Rules pozostają odrębnymi regułami. Zmiana lub usunięcie pierwotnej reguły DNAT nie aktualizuje ich ani nie usuwa automatycznie. Po zmianie adresu publicznego, wewnętrznego adresu docelowego lub usługi należy osobno sprawdzić reguły pochodne.

Jeśli reguła DNAT rozdziela ruch między kilka wewnętrznych adresów docelowych, bez opcji Health check SFOS uznaje je za dostępne. Dla metody First alive Health Check jest wymagany; w przypadku pozostałych metod rozdzielania trzeba go świadomie włączyć i skonfigurować z użyciem protokołu ICMP lub TCP odpowiednio do usługi. Dzięki temu SFOS nie będzie kierować nowego ruchu do niedostępnego serwera.

Linked NAT Rules i Server Access Assistant

Linked NAT Rule jest zawsze regułą SNAT powiązaną z regułą zapory. Nadal obowiązują wszystkie kryteria dopasowania reguły zapory, w tym użytkownicy i harmonogram. W regule NAT można zmieniać wyłącznie translated sources oraz translated sources specyficzne dla interfejsów.

Powiązanie nie omija standardowej kolejności NAT: niezależna reguła NAT umieszczona wyżej może zostać dopasowana jako pierwsza. Jeśli ogólna reguła SNAT obejmuje już ten sam ruch, Sophos nie zaleca dodawania kolejnej Linked NAT Rule. W trybie MTA SFOS tworzy jednak taką regułę automatycznie.

Server access assistant (DNAT) tworzy regułę DNAT, Reflexive Rule oraz regułę zapory. Loopback Rule jest dodawana tylko dla opisanej wcześniej kombinacji interfejsu WAN i źródła zewnętrznego Any. Kreator umieszcza reguły na początku tabel i włącza je. Następnie należy sprawdzić źródła, pozycje reguł, utworzone reguły dodatkowe i sposób użycia aliasu IP. W przypadku aliasu IP kreator początkowo ustawia interfejs fizyczny jako translated source w Reflexive lub Loopback Rules. Jeśli ma być używany adres aliasu, trzeba ręcznie wybrać odpowiedni obiekt IP Host.

Rozróżnienie NAT, VPN i SD-WAN

NAT nie zmienia decyzji o routingu. Również po translacji SFOS potrzebuje trasy do adresu docelowego. W przypadku ruchu VPN właściwe miejsce konfiguracji translacji zależy ponadto od typu tunelu:

• Policy-based IPsec: do translacji podsieci lokalnych i zdalnych, zwłaszcza gdy się pokrywają, użyj ustawień NAT połączenia IPsec. Jeśli dodatkowa reguła SNAT ma obejmować ruch policy-based, jej Outbound interface musi mieć wartość Any; reguła nie zadziała z konkretnymi interfejsami WAN.
• Route-based IPsec z wybranymi podsieciami lokalnymi i zdalnymi: do translacji tych podsieci użyj ustawień NAT połączenia IPsec.
• Route-based IPsec z Any/Any: użyj reguł NAT dla przekazywanego ruchu.

Dla ruchu VPN w regułach NAT ustaw Inbound interface na Any. Dla VPN oraz DNAT z publicznych IP na prywatne również Outbound interface musi mieć wartość Any. To wymóg dopasowania interfejsu, a nie zezwolenie dla dowolnych źródeł lub usług; nadal ograniczają je kryteria Original i reguły zapory.

Niepokrywające się sieci zazwyczaj nie wymagają NAT. W przypadku nakładających się sieci należy udokumentować po obu stronach sieci rzeczywiste i przetłumaczone; w przeciwnym razie wpisy DNS, reguły i dzienniki staną się niejednoznaczne.

Dla DNAT kierowanego do serwera za tunelem IPsec route-based Sophos opisuje specjalną konfigurację SD-WAN: reguła DNAT używa MASQ jako Translated source, aby odpowiedzi wracały do zapory. Trasa SD-WAN dopasowuje jako cel pierwotny adres WAN lub interfejs WAN, a w przypadku PAT także port zewnętrzny. Obiekt bramy wskazuje interfejs XFRM. Tego szczególnego przypadku nie należy stosować jako ogólnego wzorca DNAT dla serwerów lokalnych.

Dostęp do zdalnego serwera przez DNAT i trasę SD-WAN

Ta procedura IPv4 dotyczy wyłącznie serwera za zdalną zaporą. Najpierw sprawdź połączenia IPsec route-based na obu zaporach, stan tunelu, zdalną osiągalność, dozwolone źródła, usługę, powrót i istniejącą kolejność NAT/SD-WAN. Zapisz konfigurację i odpowiednie pozycje. Przykład używa zewnętrznego TCP 5555 i wewnętrznego TCP 443, a nie publicznego RDP; zastąp adresy dokumentacyjne własnymi wartościami. Osobna reguła zezwalająca zapory i zabezpieczenia nadal są konieczne.

1. W Hosts and services > IP host > Add utwórz Remote_Web: IP version IPv4, Type IP, IP address adres zdalnego serwera, na przykład 172.16.16.10; Save.
2. W Routing > Gateways, IPv4 gateway > Add, wybierz czytelną nazwę. Ustaw Gateway IP na adres zdalnej bramy, na przykład 10.12.13.2, a Interface na odpowiadający jej interfejs XFRM, na przykład xfrm1-10.12.13.1. W Monitoring condition wpisz adres IP rzeczywiście osiągalnego hosta za bramą; sprawdź stan bramy i tunelu przed publikacją.
3. W Rules and policies > NAT rules > Add NAT rule > New NAT rule utwórz nazwaną regułę IPv4. Ogranicz Original source do autoryzowanych źródeł zewnętrznych. Ustaw Original destination na publikowany interfejs WAN, na przykład #Port1, Translated source (SNAT) na MASQ, Translated destination (DNAT) na Remote_Web, Original service na obiekt TCP 5555, a Translated service (PAT) na TCP 443. Dla tego przypadku VPN-DNAT oba pola interfejsów ustaw na Any. Sprawdź pozycję i wybierz Save. W tym szczególnym przypadku MASQ zapewnia powrót do zapory.
4. W Routing > SD-WAN routes wybierz IPv4 > Add i podaj nazwę. W Destination networks usuń Any i wybierz ten sam pierwotny interfejs WAN #Port1, nie Remote_Web. W Services usuń Any i wybierz usługę zewnętrzną TCP 5555, nie TCP 443. W Link selection settings wybierz Primary and Backup gateways, a w Primary gateway zdalną bramę; zapasową wybierz tylko wtedy, gdy jej zdalna ścieżka istnieje i została sprawdzona. Wybierz Save.
5. Nawiąż nowe połączenie z autoryzowanego źródła zewnętrznego. Sprawdź ID NAT/zapory, przetłumaczony cel i usługę, wyjście XFRM i odpowiedzi w przechwytywaniu. Przy błędnym wyjściu sprawdź kryteria SD-WAN, kolejność i monitorowanie bramy; przy braku odpowiedzi zdalną usługę i powrót. Dla kolejnych serwerów przez tę samą bramę rozszerz tę samą trasę SD-WAN o ich porty zewnętrzne/adresy WAN; dla różnych bram użyj osobnych tras. Dodane kombinacje muszą nadal być ograniczone przez NAT i zaporę.

W razie niepowodzenia wyłącz nową regułę zdalnego DNAT, usuń nową trasę SD-WAN lub przywróć jej poprzednią konfigurację i pozycje. Nie usuwaj współdzielonych obiektów bram/hostów. Osobno wycofaj reguły NAT pochodne i sprawdź poprzedni przepływ w nowym połączeniu.

Translacja ruchu zapory za pomocą sys-traffic-nat

Reguły NAT w WebAdmin tłumaczą ruch przekazywany. Do ruchu generowanego przez zaporę oraz do translacji adresów interfejsów zapory służy polecenie sys-traffic-nat w Device Console.

Typowe zastosowania translacji źródła przez CLI:

• Wysyłanie zapytań DHCP i uwierzytelniania generowanych przez zaporę przez IPsec site-to-site; translacja może też wspierać zapytania do usług zapory przez tunele VPN. Nie zastępuje konfiguracji usług ani VPN.
• Użycie aliasów adresów, gdy łączy WAN jest więcej niż fizycznych interfejsów WAN, z translacją interfejsu fizycznego na odpowiedni alias.
• Wysyłanie poczty z adresem źródłowym aliasu wymaganym przez nadrzędny serwer przekazujący lub rekord MX.
• Ukrywanie adresów wewnętrznych przed celami WAN, na przykład zapytań DHCP interfejsu LAN; użycie określonej tożsamości źródłowej dla wewnętrznych celów MPLS lub wybranych serwerów WWW.

Najpierw zanotuj cel, wymaganą tożsamość źródłową, trasę i wymagania drugiej strony. Następnie ponownie wywołaj konkretną usługę i sprawdź adres źródłowy oraz odpowiedź w przechwytywaniu. Sam wpis CLI nie potwierdza działania DHCP, uwierzytelniania ani poczty.

Poniższy przykład tłumaczy ruch do pojedynczego adresu docelowego 192.0.2.10, przechodzący przez Port1, na adres aliasu 203.0.113.10:

show advanced-firewall
set advanced-firewall sys-traffic-nat add destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

Adres docelowy, maska sieci, interfejs i adres SNAT muszą odpowiadać danemu środowisku. Dla pojedynczego hosta wymagana jest maska 255.255.255.255; szersza maska obejmuje całą odpowiadającą jej sieć docelową. Bez parametru interface wpis dotyczy ruchu kierowanego do wskazanego celu przez dowolny interfejs zapory.

⚠️ To polecenie Device Console zmienia ruch generowany przez system. Najpierw zapisz pełny wynik polecenia show advanced-firewall. Wpisy NAT w CLI są przetwarzane w kolejności, w której są tam wyświetlane.

Aby wycofać zmianę, użyj tego samego pełnego przypisania z opcją delete:

set advanced-firewall sys-traffic-nat delete destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

Ruch generowany przez system domyślnie korzysta z WAN Link Load Balancing. W przypadku aliasu IP główny interfejs nadal decyduje o routingu; sys-traffic-nat zapewnia jedynie, że jako źródło jest widoczny wymagany adres aliasu. Widoczny wpis potwierdza więc konfigurację, ale nie trasę, ścieżkę powrotną ani działanie usługi.

Bezpieczna zmiana i testowanie reguł NAT

Świadome korzystanie z tabeli i liczników

W Rules and policies > NAT rules opcja IPv4 lub IPv6 wybiera rodzinę reguł. Disable filter ukrywa filtr, Enable filter go pokazuje, a Reset filter resetuje. Ukrycie filtra nie wyłącza reguły NAT. Przed zmianą sprawdź, czy widoczne są właściwe wpisy.

Wybrane reguły można wspólnie wyłączyć przez Disable lub usunąć przez Delete. Przeciągnij Rule handle, aby przesunąć regułę; szczegółowe powinny poprzedzać ogólne. More options oferuje przełącznik włączania, edycję, usuwanie i dodanie sąsiedniej reguły. Unlink rule usuwa powiązanie z regułą zapory: najpierw udokumentuj tę zależność i nie traktuj odłączania jako skrótu diagnostycznego.

Reset usage count w More options zeruje licznik użycia. Najpierw zanotuj wartość i czas, potem wygeneruj nowy przepływ testowy i sprawdź przyrost wraz z Rule IDs; sam licznik nie identyfikuje testowanego przepływu. Poprzednia wartość nie zostaje przywrócona. Przed zmianą reguł zapisz ID, kryteria, stan i kolejność, wybieraj wyłączenie zamiast usunięcia i zmieniaj tylko wybrane wpisy. W razie problemów przywróć stan i pozycje, a następnie testuj w nowej sesji; usuniętą regułę trzeba odtworzyć z zapisanej konfiguracji.

SFOS ocenia NAT tylko dla pierwszego pakietu połączenia. Po zmianie lub przesunięciu reguły istniejące sesje zachowują wcześniejszą translację. Test po zmianie musi zatem utworzyć nowe połączenie; w przeciwnym razie można nieświadomie oceniać poprzedni stan.

Wiarygodny test zaczyna się od zapisania parametrów przepływu: źródła, celu, usługi, interfejsu wejściowego i wyjściowego oraz oczekiwanych wartości Firewall Rule ID i NAT Rule ID. Następnie:

1. Utwórz nowe połączenie i w Log Viewer filtruj według źródła, celu i usługi.
2. Porównaj oczekiwane wartości Firewall Rule ID i NAT Rule ID.
3. Jeśli NAT Rule ID jest nieprawidłowy, sprawdź reguły znajdujące się wyżej, wszystkie pola Original oraz interfejsy.
4. W sekcji Diagnostics > Packet capture sprawdź, czy pakiet dociera do zapory i jest przekazywany z oczekiwanymi adresami.
5. Sprawdź trasę, ścieżkę powrotną, system docelowy i jego lokalną zaporę.

W przypadku DNAT co najmniej jeden test należy wykonać z zewnątrz. Dostęp wewnętrzny przy użyciu nazwy publicznej testuje tylko split DNS lub loopback, a nie rzeczywiste udostępnienie usługi w internecie.

Prawidłowa interpretacja wyników

• Firewall Rule ID i NAT Rule ID są prawidłowe: dopasowanie działa; następnie sprawdź system docelowy, ścieżkę powrotną i Security Profiles.
• Firewall Rule ID jest prawidłowy, ale NAT Rule ID jest błędny: pierwszeństwo ma inna reguła NAT albo kryteria Original nie są spełnione.
• Brak NAT Rule ID mimo oczekiwanej translacji: żadna reguła NAT nie jest dopasowana; jeśli reguła zapory zezwala na przepływ, jest on przekazywany bez translacji.
• Inny Firewall Rule ID: sprawdź strefy, sieci, usługę i kolejność reguł zapory.
• Brak wpisu w dzienniku: rejestrowanie jest wyłączone albo ruch nie dociera do zapory. Wykonaj przechwytywanie na interfejsie WAN lub wejściowym i sprawdź wcześniejsze routery albo reguły chmurowe.
• DNAT jest dopasowany, ale serwer nie odpowiada: sprawdź usługę na serwerze, lokalną zaporę, bramę domyślną i asymetryczną ścieżkę powrotną.

W dokładniejszej analizie pomogą artykuły Testowanie reguły zapory, Analizowanie dopasowania reguł, Interpretowanie odrzuconych pakietów oraz Packet Capture w WebAdmin.

Często zadawane pytania