NAT dla nakładających się sieci IPsec w Sophos Firewall
Jeśli centrala i oddział używają tej samej rzeczywistej podsieci, żaden firewall nie może na podstawie samego adresu docelowego zdecydować, czy pakiet powinien pozostać lokalnie, czy przejść przez tunel IPsec. Tunel może być zielony, mimo że nie istnieje jednoznaczna ścieżka. Rozwiązaniem jest plan translacji uzgodniony po obu stronach: każda lokalizacja jest widoczna dla peera pod unikatową siecią zastępczą.
Typ tunelu określa metodę. Policy-based IPsec oraz route-based IPsec z konkretnymi traffic selectors używają ustawień NAT bezpośrednio w połączeniu IPsec. Route-based Any-to-Any wykorzystuje natomiast reguły DNAT i SNAT oraz trasę do przetłumaczonej sieci zdalnej. Artykuł Konfiguracja VPN IPsec Site-to-Site wyjaśnia ogólny wybór typu tunelu.
Wybór właściwej metody
Sophos obsługuje translację 1:1, 1:n oraz n:n dla policy-based IPsec. Przy n:n sieć oryginalna i zastępcza muszą mieć ten sam rozmiar. Na przykład /24 należy odwzorować na inne /24, a nie na /25.
Do wyboru wystarczą trzy pytania:
- Czy w połączeniu IPsec wpisano konkretne Local i Remote subnets? Użyć Network address translation (NAT) w połączeniu.
- Czy w tunelu route-based obie podsieci ustawiono na
Any? Użyć DNAT z reflexive SNAT rule oraz trasy przez XFRM. - Czy sieci w ogóle się nie nakładają? NAT jest zwykle zbędny i utrudnia logi, reguły oraz troubleshooting.
⚠️ Nie wolno mieszać obu metod. Przed zmianą należy zabezpieczyć konfiguracje obu tuneli, reguły NAT i firewalla, trasy, odpowiedzi DNS oraz niezależny dostęp administracyjny. Szeroka reguła MASQ ani improwizowany adres zastępczy nie są bezpiecznym obejściem.
Plan adresacji dla obu lokalizacji
W przykładzie centrala i oddział używają tej samej rzeczywistej sieci 192.0.2.0/24. Każda strona otrzymuje własną sieć wirtualną dla tunelu:
HQ real: 192.0.2.0/24 → visible to branch as 198.51.100.0/24
Branch real: 192.0.2.0/24 → visible to HQ as 203.0.113.0/24
Klient w centrali łączy się więc z serwerem oddziału pod jego adresem w 203.0.113.0/24. Klient oddziału używa odpowiedniego adresu z 198.51.100.0/24 dla serwera w centrali. Rzeczywisty adres 192.0.2.x pozostaje lokalny w każdej lokalizacji.
Te trzy sieci pochodzą z bloków IPv4 zarezerwowanych do przykładów w RFC 5737 i należy je razem zastąpić wolnymi sieciami z rzeczywistego planu. Obie sieci zastępcze muszą być unikatowe, nie mogą kolidować z żadną siecią LAN, VLAN, VPN, cloud ani domową i muszą być lustrzanie udokumentowane na obu firewallach. Jeśli aplikacje używają nazw, DNS w każdej lokalizacji musi zwracać przetłumaczony adres systemu zdalnego.
Konfiguracja policy-based IPsec z NAT
W Hosts and services > IP host > Add policy-based IPsec wymaga na każdym firewallu trzech obiektów sieciowych: rzeczywistej sieci lokalnej, własnej sieci zastępczej oraz sieci zastępczej peera. W przykładzie centrali są to HO_LAN_REAL_192.0.2.0, HO_LAN_NAT_198.51.100.0 i BO_LAN_NAT_203.0.113.0.
Konfiguracja centrali
W Site-to-site VPN > IPsec > Add należy utworzyć połączenie jako Policy-based z Gateway type Respond only. Profil, uwierzytelnianie, interfejs WAN i adres peera muszą odpowiadać drugiej stronie. Należy zastosować te przypisania:
- Activate on save: włączone
- Create firewall rule: włączone
- Local subnet:
HO_LAN_NAT_198.51.100.0 - Remote subnet:
BO_LAN_NAT_203.0.113.0 - Network address translation (NAT): włączone
- Original subnet:
HO_LAN_REAL_192.0.2.0
Przed wysłaniem firewall tłumaczy rzeczywistą sieć lokalną na własną sieć zastępczą. Ruch przychodzący do sieci zastępczej jest ponownie odwzorowywany na sieć rzeczywistą.
Lustrzana konfiguracja oddziału
Taki podział ról jest szczególnie przydatny, gdy oddział ma dynamiczny adres IP, a centrala nie zna niezawodnego adresu peera, do którego mogłaby zainicjować połączenie: wtedy oddział inicjuje połączenie do stabilnie osiągalnego punktu końcowego centrali. Adres dynamiczny nie jest jednak bezwzględną przeszkodą, jeśli adres peera można niezawodnie rozwiązać, a projekt pozwala na inicjowanie połączenia z centrali. Wraz z dodawaniem kolejnych oddziałów zestawianie połączeń skaluje się lepiej, gdy każdy oddział ponawia własne próby połączenia, zamiast pozostawiać centrali ponawianie wszystkich połączeń z oddziałami.
W oddziale należy utworzyć połączenie Policy-based z Gateway type Initiate the connection. Przypisania są całkowicie odwrócone:
- Activate on save: włączone
- Create firewall rule: włączone
- Local subnet:
BO_LAN_NAT_203.0.113.0 - Remote subnet:
HO_LAN_NAT_198.51.100.0 - Network address translation (NAT): włączone
- Original subnet:
BO_LAN_REAL_192.0.2.0
Local i Remote subnet zawierają zatem sieci przetłumaczone, natomiast Original subnet zawiera rzeczywistą sieć lokalną. Jeśli rozmiar lub kierunek się nie zgadzają, Phase 2 może powstać, lecz ruch zostanie błędnie przetłumaczony albo nie znajdzie drogi powrotnej.
Kontrola automatycznych reguł firewalla
Po włączeniu Create firewall rule SFOS tworzy przychodzące i wychodzące reguły VPN. Należy je sprawdzić w Rules and policies > Firewall rules, w grupie Automatic VPN rules. Reguły muszą zezwalać na sieci zastępcze we właściwym kierunku i tylko na potrzebne usługi. Można dostosować istniejącą ogólną regułę VPN; osobna szeroka reguła dla każdego tunelu nie jest obowiązkowa.
Reguły są oceniane od góry do dołu. Te reguły VPN należy umieścić nad szerszymi regułami, które mogłyby z nimi kolidować, a podczas rzeczywistego testu sprawdzić Rule ID, strefy i sieci źródłowe oraz docelowe, usługi i logging. Artykuł Tworzenie reguł firewalla w Sophos Firewall opisuje ogólną logikę.
Zestawienie połączenia w razie potrzeby
Stan tunelu należy sprawdzić dopiero po skonfigurowaniu obu lokalizacji i zweryfikowaniu reguł firewalla. Activate on save aktywuje wpis konfiguracji, ale nie potwierdza zestawienia tunelu. Jeśli tunel nie jest jeszcze zestawiony i wymagane jest ręczne zestawienie, po stronie inicjującej – w tym przykładzie w oddziale – należy otworzyć Site-to-site VPN > IPsec i kliknąć przycisk stanu w kolumnie Connection odpowiedniego połączenia.
Nie należy w tym celu rozłączać ani ponownie zestawiać już zestawionej produkcyjnej SA; w odpowiadającej centrali takie kliknięcie nie jest wymagane. Zielony wskaźnik połączenia potwierdza zestawienie tunelu, a nie działanie ścieżki danych: następnie należy wykonać w obu kierunkach opisane poniżej kontrole usługi, Child SA i przechwytywania pakietów.
Konfiguracja route-based Any-to-Any z DNAT i SNAT
Ta metoda wymaga działającego tunelu route-based Any-to-Any. Interfejs XFRM ma unikatowy adres tranzytowy, istnieją odpowiednie reguły LAN-to-VPN i VPN-to-LAN, a trasa statyczna, SD-WAN lub dynamiczna wskazuje sieć zastępczą peera. Dopiero potem dodaje się NAT.
Połączenia route-based z konkretnymi traffic selectors nie używają tej procedury. Podobnie jak policy-based IPsec korzystają z ustawień NAT połączenia IPsec. Jest to osobna procedura Sophos, której nie należy łączyć z regułami DNAT/SNAT dla Any-to-Any.
NAT w centrali
W Rules and policies > NAT rules > Add NAT rule > New NAT rule należy utworzyć regułę DNAT. Tłumaczy ona pakiety przychodzące do wirtualnej sieci centrali na rzeczywistą sieć lokalną:
- Original source: sieć zastępcza oddziału
203.0.113.0/24 - Translated source:
Original - Original destination: sieć zastępcza centrali
198.51.100.0/24 - Translated destination: rzeczywista sieć centrali
192.0.2.0/24 - Original service:
Any - Translated service:
Original - Inbound interface:
Any - Outbound interface:
Any - Create reflexive rule: włączone
- Load balancing method:
One-to-one
Do odwzorowania należy użyć obiektów sieciowych lub IP range o takim samym rozmiarze. Po zapisaniu należy otworzyć utworzoną regułę Reflexive_NAT#_<DNAT_rule_name>. W kierunku wychodzącym musi tłumaczyć rzeczywistą sieć centrali na 198.51.100.0/24 i używać sieci zastępczej oddziału 203.0.113.0/24 jako Original destination.
NAT w oddziale
W oddziale należy zastosować ten sam schemat lustrzanie:
- Original source: sieć zastępcza centrali
198.51.100.0/24 - Translated source:
Original - Original destination: sieć zastępcza oddziału
203.0.113.0/24 - Translated destination: rzeczywista sieć oddziału
192.0.2.0/24 - Original service:
Any - Translated service:
Original - Inbound interface:
Any - Outbound interface:
Any - Create reflexive rule: włączone
- Load balancing method:
One-to-one
Reguła reflexive musi w kierunku wychodzącym tłumaczyć rzeczywistą sieć oddziału na 203.0.113.0/24. Wartość Any dla obu interfejsów jest zamierzona w tym udokumentowanym schemacie; nie należy zastępować jej WAN tylko dlatego, że peer IPsec jest osiągalny przez WAN. Obiekty przetłumaczonych adresów i reguły firewalla zapewniają wąski zakres. Bardziej ogólna reguła SNAT lub MASQ umieszczona wyżej nie może przechwycić ruchu wcześniej.
SFOS dopasowuje regułę NAT do oryginalnego źródła, celu i usługi przed NAT oraz do interfejsów wejściowego i wyjściowego. NAT stosuje się tylko do pierwszego pakietu połączenia, dlatego każdy test po zmianie NAT musi używać nowego połączenia z nową piątką parametrów. Kolejność i dopasowanie należy potwierdzić przez NAT Rule ID i Packet Capture, a nie wyłącznie wywnioskować z listy. Artykuł NAT w Sophos Firewall wyjaśnia reguły reflexive i zasadę first-match.
Dokładne dopasowanie reguł firewalla Any-to-Any
Reguła NAT nie zezwala na ruch. W Rules and policies > Firewall rules > Add firewall rule > New firewall rule należy utworzyć wąskie reguły: w centrali wychodząca używa LAN, rzeczywistej sieci centrali, VPN i sieci zastępczej oddziału, a przychodząca używa VPN, sieci zastępczej oddziału, LAN i rzeczywistej sieci centrali. W oddziale odwrócić lokalizacje, ograniczyć Services i włączyć Log firewall traffic na czas odbioru. Wynika to z kolejności NAT: firewall przed SNAT dla ruchu wychodzącego, DNAT przed firewallem dla przychodzącego.
Wspólna kontrola routingu, DNS i aplikacji
Po każdej stronie trasa do zdalnej sieci zastępczej musi korzystać z właściwego interfejsu XFRM lub jego monitorowanego gateway. Trasa do identycznej sieci rzeczywistej byłaby niejednoznaczna i mogłaby skierować ruch lokalny do tunelu. Jeśli istnieje kilka tras, należy wspólnie sprawdzić Route Precedence, Administrative Distance oraz wybór SD-WAN.
Aplikacja również musi używać przetłumaczonego celu. Konfiguracje statyczne, ACL, odpowiedzi DNS, monitoring i logi serwera nie mogą nadal oczekiwać rzeczywistego adresu zdalnego. Test NAT wyłącznie za pomocą ping nie potwierdza więc działania procesu biznesowego.
Weryfikacja przepływu w obu kierunkach
Należy rozpocząć od jednego znanego hosta i rzeczywistej usługi TCP lub UDP po każdej stronie. Sprawdzić Current activities > IPsec connections i Reports > VPN. W Diagnostics > Packet capture > Configure filtr BPF, na przykład host 203.0.113.10, ogranicza przechwytywanie do testu. Z centrali uzyskać dostęp do przetłumaczonego adresu oddziału, a następnie z oddziału przetestować przetłumaczony adres centrali. Dla tego samego znacznika czasu sprawdzić:
- Połączenie IPsec i Child SA są aktywne.
- Oczekiwana Firewall Rule ID zezwala na przepływ.
- Oczekiwana NAT Rule ID prawidłowo tłumaczy adresy oryginalne i docelowe.
- W Packet Capture pola In interface, Out interface, NAT ID, Rule ID, Status i Reason pokazują wejście, translację, wyjście XFRM oraz drogę powrotną.
- Serwer docelowy widzi zaplanowany adres źródłowy i odpowiada tą samą drogą.
W teście negatywnym należy użyć identycznego adresu rzeczywistego 192.0.2.10: musi pozostać lokalny i nie może pojawić się na interfejsie XFRM. Kolejne hosty, usługi i nazwy DNS dodaje się dopiero po oczekiwanym wyniku testu pozytywnego i negatywnego w obu kierunkach. Packet Capture w Sophos Firewall pomaga porównać pakiety przed i po NAT; Troubleshooting IPsec w Sophos Firewall opisuje pełną kontrolę tunelu.
Zawężanie błędów według objawu
Tunel jest zielony, ale cel odpowiada lokalnie
Klient prawdopodobnie używa rzeczywistego adresu, który również istnieje lokalnie, zamiast zdalnej sieci zastępczej. Należy sprawdzić odpowiedź DNS, plik hosts, konfigurację aplikacji i trasę docelową. Błąd występuje wtedy przed tunelem.
Droga w jedną stronę działa, ale brak powrotu
Translacje muszą być lustrzane na obu firewallach. Należy porównać Original i Translated source w regule reflexive, Remote subnet w połączeniu IPsec, gateway serwera oraz reguły w przeciwnym kierunku. Translacja jednostronna nie zapewni stabilnego przepływu dwukierunkowego.
Dopasowuje się niewłaściwa reguła NAT
Należy sprawdzić NAT Rule ID i kolejność. Szeroka reguła MASQ, Default-SNAT lub wcześniejsza DNAT może dopasować się przed właściwą regułą VPN. Nie należy wyłączać wszystkich reguł NAT na próbę; najpierw skorelować pojedynczy przepływ testowy według czasu, a potem poprawić tylko kolidującą regułę.
Niektóre hosty działają, a inne nie
Przy n:n zakresy oryginalny i przetłumaczony muszą mieć ten sam rozmiar i pozycję. Należy sprawdzić obiekty IP range, maski, wykluczone adresy, firewall hosta oraz faktycznie użyty offset. Sukces dla .10 nie potwierdza odwzorowania całego zakresu.
Rollback i eksploatacja
Przed zmianą należy przygotować backup konfiguracji, zrzuty lub eksporty konfiguracji tunelu, NAT, firewalla i routingu oraz niezależny dostęp administracyjny. Należy też zapisać nazwy, ID, kolejność i stan włączenia wszystkich objętych zmianą reguł i tras oraz poprzednie wartości DNS i aplikacji. Podczas migracji stare reguły wyłącza się dopiero po dokładnym udokumentowaniu ich wcześniejszego stanu.
Jeśli weryfikacja się nie powiedzie, najpierw przywrócić zapisane wartości DNS i aplikacji. Dla Any-to-Any wyłączyć tylko nowe reguły firewalla, parę DNAT/reflexive-SNAT i trasę do sieci zastępczej; dla policy-based przywrócić zapisane pola Local, Remote i Original subnet. Następnie odtworzyć wcześniejszą kolejność i stan aktywacji reguł oraz tras i przetestować nowe połączenia w obu kierunkach. Istniejące sesje zachowują mapowanie NAT ustalone przez pierwszy pakiet i nie dowodzą rollbacku: sesje niezwiązane ze zmianą należy pozostawić, a jeśli potrzebny jest natychmiastowy dowód, przed ponownym testem zakończyć tylko objęte nim sesje testowe. Nie należy usuwać wszystkich połączeń. Adresy XFRM i obiekty usunąć dopiero, gdy Object usage nie wykazuje zależności. Sieci zastępcze usuwa się z DNS, monitoringu i dokumentacji dopiero wtedy, gdy nie pozostają żadne zależności.
W eksploatacji sieci zastępcze należy prowadzić w centralnym planie adresów IP. Nowe lokalizacje, sieci cloud, pule Remote Access i sieci domowe trzeba porównywać zarówno z sieciami oryginalnymi, jak i przetłumaczonymi. W przeciwnym razie nakładanie jedynie przeniesie się w inne miejsce.