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

NAT to jeden z tematów Sophos Firewall, który w praktyce szybko staje się zagmatwany. Terminy brzmią podobnie, maska ​​reguł działa z Original i Translated, a w Log Viewer widzisz inne adresy niż oczekiwano w zależności od lokalizacji.

W tym artykule wyjaśniono najważniejsze typy NAT, przedstawiono typowe praktyczne przypadki i opisano przykład DNAT z odpowiednią regułą zapory ogniowej.

Najważniejszym praktycznym punktem jest: NAT należy rozpatrywać łącznie z regułą zapory sieciowej, routingiem, ścieżką zwrotną i rejestrowaniem. Wiele problemów z NAT wynika nie z samego tłumaczenia, ale z nieprawidłowej kolejności reguł, źle zrozumianego Original destination, braku logowania lub testów z niewłaściwej sieci.

Orientacja

Przed zbudowaniem reguły NAT powinno być najpierw jasne, który problem jest tak naprawdę rozwiązywany. NAT tłumaczy adresy lub porty, ale nie zastępuje czyszczenia zapory ogniowej i czystego projektu routingu.

Który element NAT pasuje?

NAT szybko pokrywa się z regułami zapory sieciowej, routingiem, WAF, VPN i Packet Capture. W zależności od zadania ten podstawowy artykuł nie zawsze jest najlepszym sposobem na rozpoczęcie:

• Zrozumieć NAT, SNAT, DNAT, MASQ, PAT, Loopback i reguły refleksyjne: ten artykuł.
• Opublikować serwer wewnętrzny przez przekierowanie portów: Opublikować serwer przez DNAT na Sophos Firewall.
• Udostępnić publicznie aplikację HTTP lub HTTPS: Sophos Firewall WAF: bezpiecznie opublikować serwer WWW.
• Wspólnie ocenić reguły zapory i NAT: Zrozumieć i bezpiecznie skonfigurować reguły Sophos Firewall.
• Przetestować pojedyncze połączenie z logami i Packet Capture: Przetestować regułę zapory z Log Viewer, Policy Test i Packet Capture.
• Sprawdzić NAT dla IPsec, XFRM, SD-WAN lub nakładających się sieci: Rozwiązywanie problemów z IPsec VPN w Sophos Firewall.
• Analizować dropy, Violation, Rule ID lub NAT Rule ID: Analizować odrzucone pakiety Sophos Firewall.

Dzięki temu rozwiązywanie problemów jest dokładniejsze: najpierw wyjaśnij, czy chodzi o tłumaczenie, wydanie, routing, ochronę serwera WWW czy przepływ pakietów. Następnie należy zmienić tylko dotkniętą warstwę.

NAT to tłumaczenie, a nie wydanie

Translacja adresów sieciowych zmienia adresy lub porty pakietu przechodzącego przez Sophos Firewall. Jednak NAT nie sam decyduje, czy ruch jest dozwolony.

⚠️ Reguła NAT nie zezwala na ruch. Reguła tłumaczy tylko adresy lub porty. Dla ruchu przechodzącego przez zaporę zawsze wymagana jest także odpowiednia reguła zapory sieciowej.

Typowe przypadki NAT:

• Klienci wewnętrzni uzyskują dostęp do Internetu za pośrednictwem publicznego WAN-IP.
• Serwer wewnętrzny jest publikowany za pośrednictwem publicznego IP.
• Port publiczny jest tłumaczony na inny port wewnętrzny.
• Nakładające się sieci są tłumaczone dla połączeń VPN.
• Klienci wewnętrzni uzyskują dostęp do serwera wewnętrznego za pośrednictwem publicznej nazwy DNS.

Szybka decyzja: NAT czy brak NAT?

Wiele błędów NAT pojawia się, ponieważ NAT jest używane jako rozwiązanie domyślne, mimo że wystarczający byłby routing lub reguła zapory sieciowej. Przed każdą nową regułą NAT należy najpierw zdecydować, czy rzeczywiście należy zmienić adres lub port.

• Klient z LAN powinien normalnie łączyć się z Internetem: Zwykle wystarcza ogólna reguła SNAT lub MASQ.
• Wewnętrzny serwer powinien być dostępny z Internetu: Użyj DNAT lub w przypadku HTTP/HTTPS sprawdź najpierw WAF.
• Inny port powinien być używany zewnętrznie niż wewnętrznie: Zaplanuj DNAT z PAT i dodaj odpowiednią regułę zapory sieciowej.
• Użytkownicy wewnętrzni uzyskują dostęp do tej samej publicznej nazwy FQDN: Najpierw sprawdź podział DNS, użyj pętli zwrotnej NAT tylko w razie potrzeby.
• Lokalne i zdalne sieci VPN są przejrzyste: Zwykle nie używaj NAT, ale twórz przejrzyście reguły routingu i zapory ogniowej.
• Sieci VPN nakładają się na siebie lub stacja zdalna wymaga określonego źródła: Użyj docelowego SNAT lub DNAT z udokumentowaną siecią zastępczą.
• Tylko jedna reguła zapory powinna być dozwolona lub ograniczona: Nie buduj NAT. Dostosuj regułę zapory.

Jeśli odpowiedź na pytanie „Co należy przetłumaczyć?” nie jest jasne, nie należy tworzyć reguły NAT. Następnie najpierw sprawdź przepływ pakietów, adres docelowy, ścieżkę zwrotną i Log Viewer. Zwłaszcza w przypadku wewnętrznych sieci VLAN, sieci VPN typu site-to-site bez nakładających się sieci i routowanych sieci serwerów, żaden NAT nie jest często czystszym rozwiązaniem.

Poznaj podstawy NAT

Maska reguły staje się znacznie łatwiejsza, jeśli najpierw rozróżnisz ruch oryginalny od ruchu przetłumaczonego. Będzie wtedy jaśniejsze, czy należy zmienić źródło, miejsce docelowe lub usługę.

Główny gatunek NAT

• SNAT: Tłumaczy źródło IP. Zazwyczaj, gdy wewnętrzni klienci lub serwery mają uzyskiwać dostęp do Internetu za pomocą określonego publicznego IP.
• MASQ: Tłumaczy źródło IP na IP interfejsu wychodzącego. Jest to standardowy przypadek dla LAN do WAN.
• DNAT: Tłumaczy miejsce docelowe IP. Dzięki temu serwer wewnętrzny będzie dostępny poprzez publiczny IP.
• PAT: Tłumaczy port lub usługę. Oznacza to, że port zewnętrzny wskazuje inny port wewnętrzny.
• Loopback NAT: Umożliwia dostęp wewnętrzny poprzez publiczny IP lub publiczną nazwę FQDN. Klienci wewnętrzni używają tej samej nazwy DNS co użytkownicy zewnętrzni.
• Reguła refleksyjna: Tworzy regułę źródła odblaskowego NAT. Dzięki temu opublikowany serwer może ukazywać się w ruchu wychodzącym z odpowiednią tożsamością publiczną.

Jako model mentalny pomaga: NAT nie odpowiada na pytanie „Czy ten ruch jest dozwolony?”, ale raczej „Jak powinien wyglądać adres lub port po drodze?”

Przeczytaj oryginał i poprawnie przetłumacz

W regułach NAT Original opisuje ruch docierający do Sophos Firewall. Translated opisuje to po tłumaczeniu.

• Original source: Adres źródłowy przed NAT.
• Translated source (SNAT): Adres źródłowy do NAT.
• Original destination: Adres docelowy przed NAT.
• Translated destination (DNAT): Adres docelowy po NAT.
• Original service: Usługa lub port wcześniejszy niż NAT.
• Interfejsy i VPN: Any jest często poprawne dla interfejsów przychodzących i wychodzących w scenariuszach DNAT lub VPN, ponieważ tunele VPN nie zawsze są traktowane jak zwykłe interfejsy fizyczne.
• Przetłumaczona usługa (PAT): Usługa lub port do NAT.

Jeśli występują błędy, powinieneś najpierw zanotować, jak wygląda pakiet przed NAT. Następnie definiujesz, co firewall powinien z tym zrobić.

Zaplanuj NAT przed zmianą

Przed dokonaniem zmiany NAT należy nie tylko przyjrzeć się samej regule NAT. Cały przepływ pakietów ma kluczowe znaczenie: dokąd dociera pakiet, która reguła zapory sieciowej zezwala na ruch, która reguła NAT go tłumaczy, dokąd trafia odpowiedź i jak sprawdzany jest wynik?

Te punkty powinny być jasne przed zmianą:

• Pakiet wcześniejszy niż NAT: Źródło, miejsce docelowe i usługa muszą odpowiadać stronie Original reguły NAT.
• Pakiet zgodny z NAT: Translated source, Translated destination i Translated service muszą być ustawione celowo.
• Zezwalająca reguła zapory sieciowej: NAT nie zezwala na ruch. Bez odpowiedniej reguły zapory sieciowej tłumaczenie pozostaje nieskuteczne.
• Bardziej ogólne zasady NAT: Wygrywa pierwsza pasująca reguła NAT. Szeroka reguła SNAT lub MASQ może przesłaniać bardziej szczegółowe reguły.
• Ścieżka powrotna: Wiele problemów z NAT wynika w rzeczywistości z problemów z routingiem, ścieżką powrotną lub systemem docelowym.
• Metoda testowa: Przed testowaniem należy przygotować Log Viewer, Rule ID, NAT Rule ID i Packet Capture.

Zrozumienie i bezpieczna konfiguracja reguł Sophos Firewall pomaga znaleźć właściwą regułę zapory sieciowej. Jeśli nie jest jasne, czy reguła w ogóle ma zastosowanie, lepszym sposobem na rozpoczęcie rozwiązywania problemów będzie Sophos Firewall Reguła nie ma zastosowania: sprawdź przyczyny.

Praktyczne przykłady: kiedy czego używasz?

• Klienci z LAN powinni mieć dostęp do Internetu: MASQ lub SNAT. Przykład: 10.10.10.80 wychodzi na zewnątrz z zaporą sieciową WAN-IP.
• Wewnętrzny serwer WWW powinien być dostępny z zewnątrz: DNAT. Przykład: Publiczny WAN-IP wskazuje na 172.16.16.10.
• Inny port jest używany zewnętrznie niż wewnętrznie: PAT. Przykład: Zewnętrzny TCP 5555, wewnętrzny TCP 443.
• Użytkownicy wewnętrzni używają tej samej nazwy FQDN co użytkownicy zewnętrzni: Loopback NAT. Przykład: service.example.com wskazuje na tę samą usługę wewnętrznie i zewnętrznie.
• Opublikowany serwer powinien wyglądać na wychodzący z określonym publicznym IP: SNAT lub regułą zwrotną. Przykład: Serwer pocztowy wysyła ze zdefiniowanym publicznym IP.
• Sieci VPN pokrywają się: SNAT lub DNAT. Przykład: witryna A widzi witrynę B za pośrednictwem przetłumaczonej sieci.
• Ruch wewnętrzny powinien pozostać niezmieniony: Nr NAT. Wystarczą reguły routingu i zapory sieciowej.

Nie cały ruch wymaga NAT. Pomiędzy wewnętrznymi sieciami VLAN, sieciami VPN typu lokacja-lokacja bez nakładających się sieci lub sieciami kierowanymi bezpośrednio, NAT jest często nawet szkodliwy, ponieważ dzienniki, stacje zdalne i systemy docelowe tracą prawdziwe źródło IP. Dlatego dobre planowanie NAT decyduje najpierw, czy w ogóle należy wykonać tłumaczenie.

Gatunki NAT w praktyce

Następujące typy NAT rozwiązują różne zadania. W środowiskach produkcyjnych należy świadomie wybierać, które tłumaczenie jest konieczne, zamiast używać NAT jako ogólnego obejścia problemów z routingiem.

SNAT: Źródło NAT

SNAT zmienia adres źródłowy. Klasycznym przypadkiem jest wychodzący dostęp do Internetu z LAN. Klienci wewnętrznie zachowują swoje wewnętrzne adresy IP, ale adres publiczny zapory lub zdefiniowany publiczny IP pojawia się na zewnątrz.

Typowa reguła SNAT dla LAN do WAN:

• Original source: wewnętrzna LAN lub sieć serwerów.
• Translated source (SNAT): MASQ lub stały publiczny IP.
• Original destination: Any.
• Translated destination (DNAT): Original.
• Original service: Any lub zdefiniowany Services.
• Usługa tłumaczona (PAT): Original.
• Inbound interface: interfejs wewnętrzny lub Any.
• Interfejs wychodzący: Interfejs WAN. W prostych środowiskach ogólna reguła SNAT jest często bardziej przejrzysta niż wiele indywidualnych, połączonych reguł NAT.

MASQ: Maskarada

MASQ to wygodny wariant SNAT. Domyślnie MASQ tłumaczy adres źródłowy na adres IP interfejsu wychodzącego. W przypadku normalnego dostępu do Internetu jest to zwykle WAN-IP.

W podstawowej konfiguracji Sophos Firewall ma domyślną regułę SNAT z MASQ. Jeśli nie chcesz używać tej reguły, dezaktywacja jest zwykle czystsza niż usunięcie. W przeciwnym razie domyślna reguła może pojawić się ponownie podczas tworzenia lub aktualizacji interfejsu WAN.

Przeszkoda: w przypadku sieci VPN opartych na trasach MASQ może wyglądać inaczej niż oczekiwano. Jeśli podsieci lokalne i zdalne są ustawione na Any lub używane są konfiguracje podwójne IP, zapora może używać XFRM-IP jako przetłumaczonego źródła. W Packet Capture lub tcpdump możesz następnie zobaczyć WAN-IP w zewnętrznym nagłówku i XFRM-IP w kontekście wewnętrznym. Inne przeszkody dotyczą IPsec opartego na zasadach. Jeśli przetłumaczony ruch musi być przypisany do konkretnego tunelu IPsec, trasy IPsec i ustawienie Interfejs wychodzący w regułach SNAT mogą mieć krytyczne znaczenie. Proces odbywa się w IPsec Utwórz trasę na Sophos Firewall.

NAT w sieciach VPN, SD-WAN i nakładających się

NAT szybko staje się bardziej złożony w środowiskach VPN i SD-WAN niż prosty ruch LAN do WAN. Najważniejsza zasada pozostaje ta sama: po pierwsze, oczekiwana ścieżka musi być jasna. Następnie decydujesz, czy NAT jest konieczny.

Typowe scenariusze:

• VPN typu lokacja-lokacja z unikalnymi sieciami: Przeważnie brak NAT, ale czyste reguły zapory i routing.
• VPN typu lokacja-lokacja z nakładającymi się sieciami: Docelowa reguła SNAT lub DNAT z udokumentowaną siecią zapasową.
• VPN oparty na trasach z XFRM i SD-WAN: Sprawdź razem interfejs XFRM, trasę, trasę SD-WAN i NAT.
• IPsec oparty na zasadach z przetłumaczonym ruchem: Sprawdź trasę IPsec i regułę SNAT z pasującym Outbound interface.
• Remote Access VPN do sieci wewnętrznych: Zwykle nie ma NAT, chyba że system docelowy oczekuje określonego źródła.

W przypadku nakładających się sieci nie należy improwizować NAT. Obie strony muszą wiedzieć, która sieć rzeczywista kryje się za którą siecią przetłumaczoną. W przeciwnym razie poszczególne testy działają, ale aplikacje, DNS, logowanie czy reguły dostępu stają się później trudne do zrozumienia. Jeśli tunel VPN jest zielony, ale nie przepływa żaden użyteczny ruch, NAT jest tylko jedną z kilku możliwych przyczyn. Należy wtedy równolegle sprawdzić status IPsec, Route Lookup, regułę zapory, trasę SD-WAN i Packet Capture. Do uporządkowanej procedury pasują Rozwiązywanie problemów z IPsec VPN w Sophos Firewall, routing SD-WAN dla Reply Packets i System Traffic oraz sprawdzenie MTU i MSS na Sophos Firewall przy problemach VPN.

DNAT: Miejsce docelowe NAT

DNAT zmienia adres docelowy. Można na przykład opublikować serwer wewnętrzny za pośrednictwem publicznego IP lub portu publicznego. Ruch przychodzący na adres WAN jest tłumaczony na serwer wewnętrzny.

Typowa zasada DNAT:

• Original source: Any lub sieci o zdefiniowanym źródle IP.
• Original destination: Obiekt hosta WAN-IP lub WAN.
• Original service: usługa zewnętrzna, na przykład HTTPS lub Synology_5555.
• Translated destination (DNAT): serwer wewnętrzny.
• Usługa tłumaczona (PAT): Original lub wewnętrzny port docelowy.
• Translated source (SNAT): głównie Original.
• Inbound interface: Interfejs Any lub WAN.
• Interfejs wychodzący: głównie Any i DNAT.

W przypadku usług publicznych powinieneś nie tylko zbudować NAT, ale także natychmiast sprawdzić logowanie, IPS, ograniczenia źródła, logikę geo-IP i poziom poprawek serwera docelowego. Bardziej szczegółowe instrukcje krok po kroku można znaleźć w artykule Publikuj serwer do Sophos Firewall poprzez DNAT. W przypadku aplikacji HTTP i HTTPS należy również sprawdzić, czy Sophos Firewall WAF jest lepszym rozwiązaniem niż czysty DNAT. DNAT to przekierowanie portów. WAF może zawierać nazwy hostów, certyfikaty, ścieżki, profile ochrony sieci i opcjonalnie uwierzytelnianie. W przypadku prostych usług innych niż HTTP DNAT często pozostaje poprawny; w przypadku publicznie dostępnych aplikacji internetowych WAF jest często lepszym punktem wyjścia.

PAT: Tłumaczenie adresu portu

PAT zmienia usługę lub port. W Sophos Firewall odpowiada za to pole Usługa tłumaczona (PAT).

Przykład:

• Zewnętrzny TCP 5555 na wewnętrzny TCP 443.
• Zewnętrzny TCP 20120 na wewnętrzny TCP 22.
• Zewnętrzny TCP 8443 na wewnętrzny TCP 443.

Klient zewnętrzny łączy się z portem publicznym, ale wewnętrznie adresowany jest inny port. Ważne: Protokół musi być poprawny. TCP można przetłumaczyć na TCP, UDP na UDP. Tłumaczenie z TCP na UDP nie jest czystym przekierowaniem portów.

Przykład DNAT z regułą zapory sieciowej

Przykład pokazuje typową publikację usługi wewnętrznej. Kluczowe jest to, aby reguła NAT i reguła zapory sieciowej były zgodne.

Praktyczny przykład: Publikowanie Synology za pośrednictwem DNAT

W tym przykładzie usługa powinna być dostępna poprzez publiczny WAN-IP. Usługa Synology_5555 adresowana jest z zewnątrz. Wewnętrznie serwer nasłuchuje HTTPS. Zatem reguła NAT tłumaczy publiczny adres docelowy na serwer wewnętrzny, a usługę publiczną na usługę wewnętrzną.

Reguła DNAT pole po polu

• Rule name: Nazwij wyraźnie, na przykład DNAT_SYNOLOGY_5555.
• Opis: Dokument, dlaczego reguła istnieje i kto ją utworzył. To ogromnie pomoże później.
• Rule position: Zasady szczegółowe należy przedkładać nad zasadami ogólnymi.
• Original source: Można ograniczyć w regule NAT. W praktyce często wygodniej jest zachować ograniczenie źródła w regule zapory sieciowej, dzięki czemu to samo ograniczenie nie musi być stosowane dwa razy.
• Original destination: Publiczny adres docelowy przed NAT. Lepiej jest używać obiektu hosta dla WAN-IP niż bezpośrednio interfejsu WAN. Obiekt hosta zwykle pozostaje bardziej stabilny podczas zmian lub dostosowań interfejsu.
• Original service: Usługa lub port, do którego można uzyskać dostęp z zewnątrz, na przykład Synology_5555.
• Translated source (SNAT): W przypadku klasycznych reguł DNAT zwykle Original. Zmieniaj tylko wtedy, gdy serwer wewnętrzny powinien widzieć zaporę sieciową jako źródło. Ale wtedy tracisz prawdziwego klienta IP.
• Translated destination (DNAT): Serwer wewnętrzny lub lista serwerów, na które należy przekierować.
• Przetłumaczona usługa (PAT): Wewnętrzna usługa lub port, na który należy przepisać, na przykład HTTPS. Jeśli nie jest konieczna zmiana portu, usługa pozostaje Original.
• Inbound interface: Interfejs, do którego przychodzi ruch. W przypadku DNAT często Any lub WAN. Any jest często wymagany w kontekstach VPN, ponieważ sieci VPN nie są traktowane jak normalne interfejsy.
• Interfejs wychodzący: Dla DNAT zwykle Any, ponieważ zapora sieciowa decyduje o routingu i strefie docelowej.

Utwórz regułę zapory sieciowej dla reguły DNAT

Reguła DNAT nie wystarczy. Ponadto wymagana jest reguła zapory sieciowej zezwalająca na ruch.

Dla DNAT ważne jest: Reguła zapory odnosi się do ruchu w kontekście DNAT. Na początku wydaje się to niezwykłe, szczególnie w przypadku stref docelowych i sieci docelowych.

• Source zones: Przeważnie WAN, gdy dostęp pochodzi z Internetu.
• Source networks and devices: Jeśli to możliwe, nie Any, jeśli można tego uniknąć. Lepiej używać krajów, indywidualnych adresów IP, sieci, hostów lub grup FQDN.
• Destination zones: Strefa celu wewnętrznego, na przykład SERVER lub DMZ, a nie po prostu WAN.
• Destination networks: Publiczny adres docelowy lub obiekt hosta WAN z Original destination.
• Services: Usługa zewnętrzna z Original service, czyli port, do którego klienci uzyskują dostęp z zewnątrz.
• Log firewall traffic: Włącz dla opublikowanych usług. Bez logowania Log Viewer nie jest pomocny w przypadku tej reguły. Jeśli użytkownicy globalni potrzebują dostępu, a Source networks and devices nie może zostać w znaczący sposób ograniczony, należy zaostrzyć regułę: otwieraj tylko wymagane porty, aktywuj IPS, włącz logowanie, aktualizuj system docelowy i używaj MFA, VPN lub ZTNA, jeśli to możliwe.

💡 Usługi publicznie dostępne są często bardzo szybko skanowane przez boty. Źródła zagrożeń Sophos Firewall pomagają wcześnie blokować znane złośliwe adresy IP, domeny lub adresy URL. Nie zastępuje to czystej reguły, ale znacznie zmniejsza niepotrzebny ruch botów.

Reguła sprzężenia zwrotnego: dostęp wewnętrzny poprzez publiczną nazwę DNS

Reguła sprzężenia zwrotnego jest wymagana, jeśli klienci wewnętrzni powinni łączyć się z serwerem wewnętrznym za pośrednictwem publicznego IP lub publicznej nazwy FQDN.

Przykład:

• Zewnętrznie service.example.com wskazuje publiczny WAN-IP.
• Wewnętrznie klienci używają tej samej nazwy service.example.com.
• Bez pętli zwrotnej ruch z LAN trafia do publicznego IP zapory i musi wrócić do serwera wewnętrznego.

W prostych środowiskach podzielony DNS jest często czystszy: wewnętrznie service.example.com wskazuje bezpośrednio na wewnętrzny serwer IP. W takim razie nie ma potrzeby stosowania Hairpin-NAT. Jeśli podział DNS nie jest możliwy, sensowna może być reguła sprzężenia zwrotnego.

Dzięki Server Access Assistant Sophos Firewall może automatycznie tworzyć reguły pętli zwrotnej. Działa to jednak tylko pod pewnymi warunkami, na przykład jeśli interfejs WAN jest używany jako publiczny IP i ogólnie źródła zewnętrzne są odpowiednio zdefiniowane. W przypadku reguł ręcznych pętlę zwrotną należy zaplanować świadomie, a następnie przetestować.

Reguła refleksyjna: Odzwierciedlaj ruch wychodzący z serwera

Reguła refleksyjna jest automatycznie generowaną regułą SNAT dla reguły DNAT. Ta reguła może być przydatna, jeśli chcesz, aby opublikowany serwer pojawiał się zaczynając od określonego publicznego IP. Ważne: Normalne odpowiedzi na przychodzące połączenie DNAT zwykle nie wymagają osobnej reguły refleksyjnej. Zapora stanowa zapewnia, że ​​pakiety odpowiedzi należą do istniejącego połączenia.

Powinieneś aktywować reguły refleksyjne tylko wtedy, gdy rozumiesz cel. W środowiskach z wieloma adresami IP WAN, wieloma regułami DNAT lub wieloma serwerami dodatkowa reguła SNAT może w przeciwnym razie skutkować trudnym do zrozumienia zachowaniem.

⚠️ Automatycznie wygenerowane reguły Loopback lub Reflexive pozostają niezależnymi regułami. Jeśli pierwotna reguła DNAT zostanie później zmieniona albo usunięta, te reguły pochodne nie zostaną automatycznie logicznie zaktualizowane. Po każdej zmianie reguły źródłowej powiązane reguły Loopback i Reflexive trzeba sprawdzić ręcznie.

Zaawansowane funkcje NAT

Opcje te nie są potrzebne w każdym środowisku. Stają się one ważne, gdy klienci wewnętrzni używają tej samej nazwy publicznej, w grę wchodzi wiele serwerów docelowych lub reguły NAT są tworzone na podstawie reguł zapory.

Asystent dostępu do serwera czy ręczna reguła NAT?

Server Access Assistant może automatycznie tworzyć reguły DNAT, pętli zwrotnej, zwrotne i zapory ogniowej. Jest to przydatne, jeśli chcesz szybko opublikować usługę.

W środowiskach produkcyjnych reguły ręczne są często łatwiejsze do zrozumienia:

• Możesz dokładnie zobaczyć, która reguła co robi.
• Ograniczenia źródeł są celowo utrzymywane w regułach zapory.
• Reguła NAT pozostaje węższa.
• Pozycja reguły i rejestrowanie są ustawione czysto.
• Późniejsze zmiany są już mniej zaskakujące.

Asystent jest pomocny, ale nie zastępuje zrozumienia poszczególnych zasad.

Połączone zasady NAT

Na podstawie reguły zapory sieciowej tworzona jest Połączona reguła NAT. Jest to reguła źródłowa NAT w tabeli reguł NAT.

Brzmi to praktycznie, ale ma ograniczenia:

• Większość kryteriów dopasowania pochodzi z reguły zapory sieciowej.
• W regule NAT można dostosować tylko niektóre pola NAT.
• Bardziej ogólna zasada NAT powyższa może nadal pasować jako pierwsza.
• Wiele powiązanych reguł NAT szybko powoduje, że tabela NAT jest myląca.

W przypadku nowych, prostych konfiguracji niezależna reguła NAT w Rules and policies > NAT rules jest zwykle bardziej zrozumiała. Połączone reguły NAT są szczególnie przydatne w scenariuszach migracji lub w bardzo ukierunkowanych przypadkach specjalnych.

Równoważenie obciążenia i Health Check w DNAT

DNAT może zrobić więcej niż tylko proste przekierowanie portów. Jeśli kilka serwerów wewnętrznych jest zapisanych jako Translated destination, zapora może dystrybuować ruch.

Możliwe metody:

• Okrężny: prosta dystrybucja bez utrzymywania sesji.
• Pierwszy żywy: serwer główny z przełączaniem awaryjnym.
• Losowy: losowy rozkład.
• Przyklejony IP: ta sama kombinacja źródła i miejsca docelowego pozostaje na tym samym serwerze.
• One-to-one: stałe przypisanie pomiędzy oryginałem i przetłumaczonym miejscem docelowym. Jeśli chcesz, aby zapora sieciowa wykrywała, czy serwer docelowy jest dostępny, należy włączyć opcję Kontrola stanu. Bez Health Check zapora uważa serwery za dostępne, nawet jeśli nie odpowiadają.

Zamówienie NAT

Sophos przetwarza reguły NAT od góry do dołu. Pierwsza pasująca reguła wygrywa. Następnie dalsze reguły NAT nie będą już sprawdzane.

Zalecenie:

• Ustawiono określone zasady DNAT
• Szczegółowe zasady SNAT powyżej ogólnych zasad MASQ
• Świadomie ustaw domyślną regułę SNAT
• Regularnie sprawdzaj powiązane zasady NAT
• Usuń lub dezaktywuj stare reguły migracji, jeśli nie są już potrzebne

Sprawdzona kolejność w wielu środowiskach wygląda następująco:

1. Czarna dziura DNAT lub reguły blokujące dla znanych niepożądanych źródeł, jeśli takie reguły są stosowane.
2. Bardzo szczegółowe zasady DNAT dla opublikowanych usług.
3. Specjalne zasady SNAT dla poszczególnych serwerów, sieci partnerskich lub specjalne przypadki VPN.
4. Zasady pętli zwrotnej lub refleksyjne, gdy są świadomie potrzebne.
5. Ogólne zasady SNAT lub MASQ dotyczące normalnego dostępu do Internetu.

Nie jest to twarde i szybkie prawo, ale stanowi dobre ramy testowe. Konkretny przebieg testu jest zawsze kluczowy. Jeśli nad konkretną regułą zostanie umieszczona ogólna reguła MASQ lub stara połączona reguła NAT, nowa reguła będzie wyglądać na poprawną, ale nigdy nie zostanie osiągnięta. Dokonując zmian, należy sprawdzić nie tylko samą regułę, ale także reguły znajdujące się bezpośrednio nad nią i pod nią.

W przypadku usług publicznych reguła czarnej dziury DNAT przed produktywną regułą DNAT może być użyteczna, jeśli niektóre złe listy lub kraje IP mają zostać przechwycone wcześniej. Proces opisano w Sophos Firewall: Blokuj kraje i złośliwe adresy IP.

NAT bezpiecznie zmień i sprawdź

Zmiany NAT zmieniają przepływ pakietów. Dlatego powinieneś potraktować to jak produktywną zmianę: przygotować, przetestować, zarejestrować i w razie potrzeby wycofać w sposób czysty.

Bezpiecznie wdrażaj zmiany NAT

Zmiany NAT często natychmiast wpływają na ruch produktywny. Jest to szczególnie istotne w przypadku opublikowanych serwerów, specjalnych przypadków VPN, wielu adresów WAN-IP lub reguł zapory sieciowej używanych przez partnerów zewnętrznych. Dlatego NAT nie powinien być traktowany jak zwykła zmiana obiektu, ale raczej jak niewielka zmiana ze ścieżką testową i rezerwową.

Zanim dokonasz produktywnej zmiany, powinieneś krótko pamiętać:

• Poprzedni NAT Rule ID i nazwa reguły: W Log Viewer możesz następnie sprawdzić, czy nowa reguła rzeczywiście ma zastosowanie.
• Oczekiwany przebieg testu: Źródło, miejsce docelowe, usługa i kierunek muszą być jasne przed zapisaniem.
• Zależna reguła zapory: NAT i reguła zapory muszą być zgodne, ale należy je sprawdzić osobno.
• Ścieżka awaryjna: W przypadku problemów nową regułę można dezaktywować i ponownie aktywować starą regułę.
• Okno testowe: Usługi zewnętrzne, zdalne witryny VPN lub dostęp do partnerów nie powinny zostać niezauważone.

W przypadku wprowadzania większych zmian zalecamy najpierw zduplikowanie istniejących reguł NAT lub utworzenie nad nimi nowej, konkretnej reguły, zamiast bezpośredniej konwersji jedynej działającej reguły. Stara zasada początkowo pozostaje dezaktywowana lub pozostaje poniżej jako odniesienie. Po pomyślnym teście można go usunąć lub wyraźnie udokumentować.

Pozycja reguły jest również ważna: nowa, konkretna reguła SNAT lub DNAT jest bezużyteczna, jeśli powyższa bardziej ogólna reguła pasuje już do tego samego ruchu. Dlatego zmiana zawsze obejmuje test przeglądarki logów z oczekiwanymi Firewall Rule ID i NAT Rule ID. W przypadku usług dostępnych z zewnątrz test należy przeprowadzić nie tylko z poziomu własnego LAN. Wewnętrzny test publicznej nazwy FQDN często sprawdza pętlę zwrotną lub podział DNS, ale nie sprawdza prawdziwego dostępu z Internetu. Akceptacja DNAT wymaga co najmniej jednego testu zewnętrznego, na przykład za pośrednictwem komunikacji mobilnej, lokalizacji zewnętrznej lub testu kontrolowanego portu.

Sprawdź razem NAT i regułę zapory

Częstym błędem myślenia jest: „Reguła NAT jest poprawna, więc powinna działać”. To tylko połowa prawdy.

Aby ruch działał, potrzebujesz:

1. Routing do zapory ogniowej
2. odpowiednią regułę NAT, jeśli konieczne jest tłumaczenie
3. odpowiednia reguła zapory sieciowej
4. poprawna trasa powrotna
5. odpowiednie profile zabezpieczeń
6. brak blokowania typu upstream, na przykład router dostawcy, grupa zabezpieczeń w chmurze lub docelowa zapora sieciowa Poniższe informacje dotyczą również DNAT: Reguły zapory sieciowej dla ruchu DNAT używają strefy docelowej po NAT, ale publiczny adres docelowy przed NAT jako sieć docelową. Właśnie ten punkt ma kluczowe znaczenie w przypadku wielu problemów.

Przeczytaj poprawnie Firewall Rule ID i NAT Rule ID

W przypadku błędów NAT należy nie tylko sprawdzić, czy istnieje jakiś wpis w logu. Kluczowe jest to, czy wpis w logu jest zgodny z oczekiwaną regułą zapory sieciowej i oczekiwaną regułą NAT. Z tego powodu Firewall Rule ID i NAT Rule ID są bardziej pomocne niż sama nazwa reguły, ponieważ nazwy można zmieniać, wybierać podobnie lub wycinać na zrzutach ekranu.

Krótka interpretacja pomaga:

• Widoczne oczekiwane Firewall Rule ID i oczekiwane NAT Rule ID: Dopasowanie reguł jest zasadniczo prawidłowe. Następnie sprawdź ścieżkę zwrotną, system docelowy, profil bezpieczeństwa i aplikację.
• Oczekiwano, że Firewall Rule ID będzie widoczne, ale jest nieprawidłowe. NAT Rule ID: Reguła zapory sieciowej jest zgodna, ale zamówienie NAT lub kryteria NAT nie są zgodne. Sprawdź pozycję reguły NAT, pola Original i bardziej ogólne reguły NAT.
• Widoczne inne Firewall Rule ID: Wygrywa kolejna reguła zapory sieciowej. Sprawdź kolejność reguł zapory, strefy, źródło, miejsce docelowe i usługę.
• Nie widać NAT Rule ID, chociaż oczekiwano NAT: Nie zastosowano reguły NAT lub przeglądany jest nieprawidłowy typ dziennika lub przepływ. Sprawdź kryteria NAT, kierunek i rzeczywisty przebieg testu.
• Brak widocznego wpisu w dzienniku: Brak dziennika lub ruch nie dociera do zapory sieciowej. Sprawdź rejestrowanie reguł, router dostawcy, VLAN, Gateway i Packet Capture. Zwłaszcza w przypadku DNAT pojedynczy udany lub nieudany test bez porównania identyfikatora nie wystarczy. Należy zanotować, jakich identyfikatorów się oczekuje, uruchomić test dokładnie raz, a następnie porównać Log Viewer i Packet Capture. Jeśli identyfikatory nie odpowiadają oczekiwaniom, najpierw poprawiane jest dopasowanie i kolejność, a nie serwer docelowy.

Typowe błędy NAT

W przypadku problemów z NAT pomocne jest, aby nie od razu przebudowywać reguł. W pierwszej kolejności należy sklasyfikować zaobserwowaną wadę.

• Brak wpisów w dzienniku w Log Viewer: Ruch nie dociera do zapory ogniowej, brakuje dziennika lub filtr jest nieprawidłowy. Sprawdź router dostawcy, grupę zabezpieczeń chmury, klienta Gateway, rejestrowanie reguł zapory sieciowej i filtry.
• Wpis dziennika bez oczekiwanego NAT Rule ID: Reguła NAT nie pasuje lub wygrywa reguła powyżej. Original source, Original destination, sprawdź serwis i zamówienie NAT.
• Reguła DNAT pasuje, połączenie nadal nie działa: Zablokowana reguła zapory sieciowej, serwer docelowy, trasa powrotna lub zapora serwera lokalnego. Porównaj Firewall Rule ID, Packet Capture i logi serwera.
• Wewnętrzny dostęp do publicznej nazwy FQDN nie działa: Brak podzielonego DNS lub pętli zwrotnej NAT. Sprawdź wewnętrzną rozdzielczość DNS i zdecyduj, czy podzielony DNS czy pętla zwrotna są czystsze.
• Klient zewnętrzny widzi nieprawidłowe źródło - IP: SNAT lub reguła refleksyjna nieoczekiwanie zmienia źródło. Sprawdź Translated source (SNAT) i automatycznie wygenerowane reguły.
• Ruch VPN wykorzystuje nieoczekiwane źródło IP: Trasy SNAT, XFRM, SD-WAN lub IPsec nie są zgodne. Sprawdź wyszukiwanie trasy, trasę SD-WAN, trasę IPsec i pozycję reguły NAT.
• Port publiczny wskazujący na niewłaściwą usługę wewnętrzną: PAT lub obiekt usługi jest ustawiony niepoprawnie. Porównaj Original service i Translated service (PAT). To zestawienie nie zastępuje analizy przepływu pakietów, ale pozwala zaoszczędzić czas: oddziela problemy przed zaporą ogniową, w logice NAT, w regule zapory i w systemie docelowym.

Test akceptacyjny po zmianach NAT

Po zmianie NAT należy nie tylko sprawdzić, czy pojedynczy ping lub strona internetowa działa raz. Test musi być dopasowany do rodzaju tłumaczenia.

Dla SNAT lub MASQ:

1. Zdefiniuj klienta testowego i usługę docelową.
2. Sprawdź regułę zapory sieciowej za pomocą Log firewall traffic.
3. W Log Viewer sprawdź, które Firewall Rule ID i NAT Rule ID obowiązują.
4. W systemie docelowym lub zewnętrznej usłudze testowej sprawdź, które źródło IP jest widoczne.
5. Przetestuj ścieżkę powrotną i zachowanie sesji na kilku łączach WAN.

Dla DNAT lub PAT:

1. Przeprowadź test spoza własnej sieci, a nie tylko z poziomu LAN.
2. Porównaj publiczny cel IP, port zewnętrzny i wewnętrzny serwer docelowy.
3. Sprawdź Log Viewer Firewall Rule ID i NAT Rule ID.
4. Użyj Packet Capture, aby sprawdzić, czy pakiety docierają i są przesyłane do serwera wewnętrznego.
5. Sprawdź na serwerze docelowym, czy lokalna zapora sieciowa, usługa i trasa zwrotna są prawidłowe.

Dla VPN-NAT:

1. Sprawdź status tunelu i powiązania bezpieczeństwa.
2. Zdefiniuj konkretny przepływ testowy ze źródłem, miejscem docelowym i usługą.
3. Sprawdź pozycję reguły NAT i wyszukaj trasę.
4. Użyj Packet Capture po obu stronach, jeśli zdalna lokalizacja umożliwia dostęp.
5. Dołącz logi z aplikacji lub systemu docelowego, aby ocenić nie tylko stronę zapory ogniowej.

Szczególnie w odległych lokalizacjach należy zmienić tylko jeden przypadek testowy na zmianę. Jeśli reguła zapory ogniowej, NAT, trasa, SD-WAN i system docelowy zostaną dostosowane w tym samym czasie, trudno będzie później wytłumaczyć udany test.

Rozwiązywanie problemów

To zamówienie pomaga w przypadku problemów z NAT:

1. Otwórz Przeglądarkę logów i filtruj według źródła IP, miejsca docelowego IP i usługi.
2. Sprawdź, które Firewall Rule ID i NAT Rule ID są wyświetlane.
3. Sprawdź położenie sterowania NAT.
4. Sprawdź pozycję reguły zapory sieciowej.
5. Użyj opcji Diagnostics > Przechwytywanie pakietów, aby sprawdzić, czy pakiety docierają i czy są kontynuowane.
6. W celu głębszej analizy sprawdź nat_rule.log, firewall_rule.log i fwlog.log.
7. Dla kontekstu VPN lub XFRM sprawdź także charon.log, strongswan.log i xfrmi.log. Jeśli reguła NAT nadal nie działa, Reguła zapory sieciowej nie działa: sprawdź kolejność, dopasowanie i logi i Użyj narzędzia Packet Capture w WebAdmin pomogą Ci zawęzić zakres. Które nazwy usług i pliki dziennika są istotne, można znaleźć w Sophos Firewall Rozwiązywanie problemów: Services i dzienniki. W przypadku zgłoszeń do pomocy technicznej możesz wyeksportować dzienniki za pomocą opcji Sophos Firewall Zapisz dzienniki do celów wsparcia i analizy.

Lista kontrolna zasad NAT

• Reguła NAT ma unikalną nazwę i opis.
• Cel, osoba odpowiedzialna i ostatni przegląd są udokumentowane.
• Pola Original i Translated zostały przetestowane w porównaniu z rzeczywistym przepływem testowym.
• Reguła NAT przewyższa bardziej ogólne zasady NAT.
• Istnieją odpowiednie reguły zapory sieciowej i aktywne jest rejestrowanie.
• Oczekiwane Firewall Rule ID i NAT Rule ID zostały sprawdzone w Log Viewer.
• W przypadku DNAT strefa docelowa jest ustawiona poprawnie po NAT, a sieć docelowa przed NAT.
• DNAT został przetestowany zewnętrznie, a nie tylko wewnętrzny LAN.
• W przypadku usług publicznych sprawdzono ograniczenia źródłowe, IPS, alternatywę WAF i poziom łatki.
• W przypadku VPN-NAT udokumentowane są routing, trasa IPsec, SD-WAN i nakładające się sieci.
• Loopback lub podział DNS to świadoma decyzja.
• Reguły refleksyjne są aktywne tylko wtedy, gdy wychodzący ruch serwera naprawdę wymaga odzwierciedlenia.
• Stare lub tymczasowe reguły NAT zostały wyłączone lub usunięte.

Często zadawane pytania