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.

Wybór rozdzielania ruchu między cele DNAT

Wybierz Load balancing method według wymaganego zachowania, nie tylko liczby serwerów:

• Round robin: połączenia trafiają kolejno do celów. Dla 10.10.10.1 do 10.10.10.3 czwarte żądanie wraca do .1. Zapewnia to rozdzielanie bez trwałego przypisania sesji.
• First alive: wszystkie żądania trafiają do pierwszego dostępnego serwera; pozostałe są zapasowe. Health Check określa moment przełączenia.
• Random: wybór losowy, bez stałego przypisania klienta.
• Sticky IP: hash źródła i pierwotnego celu przypisuje tę parę do serwera. Przy włączonym Health Check dostępny cel przejmuje ruch po awarii. Po powrocie pierwotnego serwera wracają do niego tylko nowe połączenia; istniejące sesje są zachowane.
• One-to-one: pierwszy cel pierwotny do pierwszego przetłumaczonego, drugi do drugiego itd. Obie listy muszą zawierać tyle samo adresów IP. To stałe mapowanie DNAT, a nie przydzielanie z puli SNAT.

W Health check wybierz Probe method ICMP lub TCP, a dla TCP rzeczywisty port do sprawdzenia. Probe interval określa odstęp między kontrolami, Response time-out termin odpowiedzi, a Deactivate host after liczbę nieudanych prób. Ping potwierdza osiągalność hosta, nie działanie usługi WWW. Dostosuj czasy do usługi: zbyt czułe wartości mogą niepotrzebnie wykluczać wolny cel. Przed produkcją sprawdź rozdzielanie na nowych połączeniach oraz zaplanowaną awarię i powrót. Zapisz poprzednią metodę i parametry kontroli do wycofania zmiany.

Sprawdzenie konfliktów portów przed publikacją

Przed przekierowaniem HTTPS zanotuj rzeczywiste porty WebAdmin, User Portal i VPN Portal w Administration > Admin and user settings. Nie ustalaj na podstawie starszej instrukcji NAT, która usługa zajmuje 443. WebAdmin i User Portal wymagają osobnych, unikalnych portów. Najpierw rozwiązuj konflikty innym publikowanym IP lub portem zewnętrznym; nie zmieniaj portów zarządzania bez przygotowania. Jeśli zmiana jest konieczna, zapewnij niezależną ścieżkę zarządzania, a następnie osobno przetestuj portale, klientów VPN i zewnętrzny dostęp DNAT. Instrukcja DNAT opisuje publikację.

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.

Ostrożne usuwanie zmigrowanych reguł Linked MASQ

Po migracji pod filtrem może pojawić się komunikat. Delete linked NAT rules (only MASQ; Destination: WAN) usuwa tylko powiązane reguły ze źródłem przetłumaczonym MASQ, których reguła zapory używa wyłącznie strefy docelowej WAN. Nie jest to czynność bez ryzyka: użytkownicy, harmonogramy i wcześniejsza kolejność mogą stanowić część zamierzonego zachowania.

Najpierw zapisz konfigurację, ID i odpowiednie przepływy. Wyłączona Default SNAT IPv4 lub Default SNAT IPv6 albo świadomie zaplanowana niezależna reguła SNAT musi zastąpić wymaganą translację na właściwej pozycji. Sprawdź zastępstwo i ograniczenia zapory, włącz je i porównaj nowe dozwolone i zabronione przepływy przed usunięciem starych reguł. Przy różnicach przywróć zapisane reguły i kolejność. Understood. Don’t delete rules zachowuje reguły i trwale ukrywa komunikat; X ukrywa go tymczasowo. W razie wątpliwości najpierw dokumentuj, nie usuwaj.

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.

⚠️ 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.

Zaloguj się do Command-line console i wybierz 4 – Device Console, nie Advanced Shell. 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.

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.

Interpretacja NATRule w XML API

W automatyzacji NATRule odwzorowuje ten sam model Original/Translated. Opis obiektu Add NAT policy / Edit NAT policy jest identyczny w porównywanych dokumentacjach SFOS 22 i SFOS 23. Przed dalszym działaniem sprawdź odpowiedź i zapisany stan w używanym buildzie. Przed zadaniem zapisu obowiązują centralne zasady bezpieczeństwa XML API: ściśle ograniczony dostęp administracyjny, weryfikacja TLS, osobne konto serwisowe, chronione sekrety, kopia zapasowa, zapytanie odczytu oraz jawna operacja w Set, potwierdzona dla danego obiektu i zainstalowanego buildu. Sam opis obiektu nie jest kompletnym żądaniem gotowym do wykonania.

Kryteria dopasowania, translacja i tożsamość reguły

• OriginalSourceNetworks zawiera powtarzalne wpisy Network dla pierwotnych źródeł; OriginalDestinationNetworks zawiera wpisy Network dla pierwotnych celów. OriginalServices zawiera powtarzalne wpisy Service. Są to odwołania do obiektów służące do dopasowania przed NAT, a nie zezwolenie na ruch w zaporze. Dokumentacja podaje limit 60 znaków dla każdej z tych nazw sieci i usług.
• TranslatedSource, TranslatedDestination i TranslatedService są pojedynczymi wartościami określającymi translację. Dla pola, które ma pozostać bez zmian, przykład używa Original; dla maskarady źródła — MASQ. Oznaczenia takie jak IPAddress, IPRange, IPList, FQDN lub TCPUDP_Service opisują w przykładzie odpowiedni typ obiektu, a nie dowolną wartość dosłowną do wysłania. Sprawdź faktycznie istniejące obiekty hostów, zakresów, list, FQDN i usług oraz ich obsługę w danym buildzie. Opisane wcześniej ograniczenia PAT pozostają w mocy. Dla wartości lub nazwy obiektu usługi w TranslatedService tabela parametrów wyraźnie określa maksymalną długość 60 znaków; dla TranslatedSource i TranslatedDestination ta tabela nie podaje odpowiadającej jej maksymalnej długości.
• InboundInterfaces i OutboundInterfaces zawierają powtarzalne wpisy Interface. Ograniczają dopasowanie interfejsów, ale nie tworzą trasy. Wyjaśnione wyżej warunki VPN/DNAT obowiązują również w automatyzacji: wejście i wyjście VPN używają Any; przy DNAT z adresów publicznych na prywatne wyjście również ma wartość Any. Nie znosi to ograniczeń wynikających z kryteriów Original i reguł zapory.
• Name bezpośrednio pod NATRule jest wymaganą nazwą reguły: maksymalnie 60 znaków, UTF-8 jest dozwolone, bez przecinka. Description jest opcjonalne i ograniczone do 255 znaków. IPFamily dopuszcza IPv4 lub IPv6; dokumentacja podaje IPv4 jako wartość domyślną. Status dopuszcza Enable lub Disable; udokumentowany stan domyślny to włączony. Świadomie ustaw rodzinę i stan w zatwierdzonym payloadzie zapisu, zamiast polegać na niezweryfikowanych wartościach domyślnych.
• LinkedFirewallrule jest w przykładzie przeznaczone wyłącznie do tworzenia Linked NAT Rule w żądaniu Set. W tym celu dokładnie zidentyfikuj istniejącą regułę zapory. Powiązanie nie zmienia reguły SNAT w regułę DNAT ani nie gwarantuje jej priorytetu; ograniczenia Linked NAT nadal obowiązują.

Osobne planowanie pozycji i nadpisania dla interfejsu

Position w przykładzie XML przedstawia wartości top, bottom, after i before w tej pisowni. Przy pozycjonowaniu względnym After lub Before zawiera własne Name z nazwą reguły odniesienia. Ta nazwa nie jest wymaganą nazwą nowej lub edytowanej reguły. Przykład wyraźnie oznacza oba bloki jako mające zastosowanie wyłącznie do żądań Set. Użyj tylko odniesienia odpowiadającego żądanej pozycji; nie kopiuj bezrefleksyjnie obu przykładowych bloków. Najpierw sprawdź istnienie i aktualną pozycję reguły odniesienia, a następnie skontroluj faktycznie zapisaną kolejność. Status obiektu wskazujący powodzenie nie dowodzi jeszcze, że planowany ruch dopasuje tę regułę jako pierwszą.

OverrideInterfaceNATPolicy jest osobnym przełącznikiem z wartościami Enable lub Disable, udokumentowaną wartością domyślną Disable i odniesieniem do translacji źródła SNAT specyficznej dla interfejsu. Odpowiednia InterfaceNATPolicyList należy do planowanego przypadku tylko przy włączonym nadpisaniu. Zawiera powtarzalne bloki Override z specific_interface dla interfejsu wyjściowego i specific_translatedsourceid dla żądanego przetłumaczonego źródła na tym interfejsie. Konkretny interfejs opisany jako pole wymagane jest zatem wymagany w ramach tego warunkowego przypadku nadpisania, a nie dla każdej reguły NAT.

Komentarze w przykładzie w jednym miejscu używają odmiennej nazwy OverrideInterfaceDefaultNATPolicy, podczas gdy element i tabela parametrów używają OverrideInterfaceNATPolicy. Nie twórz na tej podstawie dodatkowego tagu XML. Lista jest opisana w tabeli jako opcjonalna z wartością domyślną NULL; nie jest to polecenie wysłania tekstu NULL. Również dla wspomnianego tam monitorindex przykład nie wskazuje jednoznacznego miejsca umieszczenia. Jeśli automatyzacja zależy od takich niewyjaśnionych szczegółów, przed zapisem wyjaśnij je w API help zainstalowanego buildu lub z pomocą wsparcia technicznego; nie zgaduj dodatkowej składni ani działania.

Pola Load Balancing i Health Check mają zastosowanie warunkowe

NATMethod ma znaczenie w przypadku rozdzielania ruchu DNAT, a nie jako wymagany wybór dla zwykłej reguły SNAT. Dokumentacja API opisuje jego zastosowanie dla strefy źródłowej WAN serwera Hosted Server oraz serwera Protected Server typu IP Range lub IP List. Nie przenoś tych starszych określeń do żądania jako dodatkowych pól XML, których nie ma w przykładzie. Udokumentowane wartości to Round-robin, First_alive, Random, StickyIP i OnetoOne; wartość domyślna w dokumentacji nosi nazwę Sticky IP. Wskazówki dotyczące wyboru spośród pięciu metod oraz wymóg równej liczby adresów dla One-to-one podano wyżej.

HealthCheck dopuszcza Enable lub Disable i w tabeli API jest opisane jako opcjonalne, z wartością domyślną OFF oraz mające zastosowanie wyłącznie przy Load Balancing. Nie oznacza to, że każde żądanie NAT wymaga pól Health Check. Nie jest to jednak także zapewnienie, że First_alive ma działać bez kontroli: szczegółowe instrukcje NAT wymuszają Health Check dla First alive. W tym przypadku świadomie zaplanuj kontrolę i jej parametry oraz sprawdź je w zapisanym stanie, zamiast polegać na ogólnej wartości domyślnej OFF.

Przy włączonym Health Check parametry kontroli znajdują się w bloku LoadBalance:

• ProbeMethod: ICMP lub TCP. Oznaczenie pola jako wymaganego dotyczy tutaj przypadku aktywnej kontroli.
• Port: tylko dla TCP, zakres 1–65535; nie wyciągaj z tego ogólnego wymogu podania portu dla ICMP.
• ProbeInterval: odstęp między kontrolami w sekundach, zakres 5–65535, udokumentowana wartość domyślna 60. Zakres pochodzi z tabeli parametrów; pusty element w przykładzie nie określa własnej wartości liczbowej.
• ResponseTimeOut: limit czasu odpowiedzi w sekundach, zakres 1–10, udokumentowana wartość domyślna 2.
• DeactivateHostAfter: liczba nieudanych prób kontroli do dezaktywacji, pole opcjonalne, zakres 1–10, udokumentowana wartość domyślna 3.

Nie odrywaj oznaczeń wymaganej metody, odstępu między kontrolami i limitu czasu odpowiedzi od kontekstu włączonego Health Check. Również te informacje potwierdzają jedynie opisany kontrakt API. Działanie kontroli, usługi i oczekiwanego przełączania awaryjnego trzeba zweryfikować za pomocą opisanego wyżej nowego przepływu danych oraz zaplanowanego testu awarii i powrotu.

Interpretacja odpowiedzi NATRule właściwa dla obiektu

Poniższe przypisania pochodzą z Status Message Information dla tego obiektu. Są to kody statusu obiektu XML, a nie kody statusu HTTP. Wartości Message.* są nierozwiązanymi kluczami komunikatów z dokumentacji, a nie zweryfikowanymi tekstami komunikatów zapory. Dlatego oceniaj łącznie operację, kod, rzeczywistą odpowiedź i zapisany stan; nie wywnioskuj z nazwy klucza wartości granicznej ani bezpieczeństwa ponowienia próby.

• Add NAT policy: 200 jest powiązany z Message.NATPolicyAddSuccess, 500 z Message.NATPolicyAddFail, a 502 z Message.NATPolicyRecordExists.
• Edit NAT policy: 200 jest powiązany z Message.NATPolicyUpdateSuccess, 500 z Message.NATPolicyUpdateFail, a 502 z Message.NATRuleUpdateRecordExist. W szczególności klucz dla 502 różni się od klucza używanego przy tworzeniu.

Dla obu operacji Add NAT policy i Edit NAT policy udokumentowano dodatkowo te same przypisania:

W szczególności nie wolno więc interpretować tutaj 504 wyłącznie na podstawie ogólnej tabeli API jako nieudanego usunięcia z powodu odwołania: te wiersze NATRule dotyczą Add/Edit i zawierają klucz konfliktu portów. Również kody 548 i 549, mimo identycznego klucza, nie potwierdzają konkretnej maksymalnej liczby serwerów.

Przed każdą ponowną próbą zapisu, także po przekroczeniu limitu czasu lub pozornym powodzeniu, odczytaj faktycznie zapisany wpis NAT i sprawdź go w Rules and policies > NAT rules: nazwę, rodzinę, stan, wartości Original/Translated, interfejsy, przypisania nadpisania, warunkowe parametry kontroli i pozycję. Porównaj odpowiedź z wcześniej zabezpieczonym stanem; w razie konfliktów nie obchodź ich przez zmianę nazwy, rozszerzenie kryteriów ani bezrefleksyjne ponawianie. Niewyjaśnione różnice wymagają zatrzymania zadania. Dopiero po sprawdzeniu stanu skontroluj w nowej sesji oba Rule IDs i rzeczywistą translację. Aby wycofać zmianę, przywróć zabezpieczony stan i kolejność oraz osobno uwzględnij reguły pochodne; praktyczna procedura publikowania serwera pozostaje w procedurze DNAT.

Często zadawane pytania