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.168.2.0/24. Każda strona otrzymuje własną sieć wirtualną dla tunelu:
HQ real: 192.168.2.0/24 → visible to branch as 192.168.1.0/24
Branch real: 192.168.2.0/24 → visible to HQ as 192.168.3.0/24
Klient w centrali łączy się więc z serwerem oddziału pod jego adresem w 192.168.3.0/24. Klient oddziału używa odpowiedniego adresu z 192.168.1.0/24 dla serwera w centrali. Rzeczywisty adres 192.168.2.x pozostaje lokalny w każdej lokalizacji.
Te trzy sieci są wartościami dokumentacyjnymi 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
Policy-based IPsec wymaga na każdym firewallu trzech obiektów IP host: rzeczywistej sieci lokalnej, własnej sieci zastępczej oraz sieci zastępczej peera. W przykładzie centrali są to HO_LAN_REAL_192.168.2.0, HO_LAN_NAT_192.168.1.0 i BO_LAN_NAT_192.168.3.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:
- Local subnet:
HO_LAN_NAT_192.168.1.0 - Remote subnet:
BO_LAN_NAT_192.168.3.0 - Network address translation (NAT): włączone
- Original subnet:
HO_LAN_REAL_192.168.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
W oddziale należy utworzyć połączenie Policy-based z Gateway type Initiate the connection. Przypisania są całkowicie odwrócone:
- Local subnet:
BO_LAN_NAT_192.168.3.0 - Remote subnet:
HO_LAN_NAT_192.168.1.0 - Network address translation (NAT): włączone
- Original subnet:
BO_LAN_REAL_192.168.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. Podczas rzeczywistego testu należy 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ę.
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. Jeśli ich ruch trafi zamiast tego na regułę MASQ, SFOS może go odrzucić, ponieważ tym interfejsom XFRM nie przypisuje się adresu IP.
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
192.168.3.0/24 - Translated source:
Original - Original destination: sieć zastępcza centrali
192.168.1.0/24 - Translated destination: rzeczywista sieć centrali
192.168.2.0/24 - 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 192.168.1.0/24 i używać sieci zastępczej oddziału 192.168.3.0/24 jako Original destination.
NAT w oddziale
W oddziale należy zastosować ten sam schemat lustrzanie:
- Original source: sieć zastępcza centrali
192.168.1.0/24 - Translated source:
Original - Original destination: sieć zastępcza oddziału
192.168.3.0/24 - Translated destination: rzeczywista sieć oddziału
192.168.2.0/24 - 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 192.168.3.0/24. Bardziej ogólna reguła SNAT lub MASQ umieszczona wyżej nie może przechwycić ruchu wcześniej. 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.
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. 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.
- Packet Capture pokazuje wejście, translację, wyjście XFRM oraz drogę powrotną.
- Serwer docelowy widzi zaplanowany adres źródłowy i odpowiada tą samą drogą.
Dopiero gdy działają oba kierunki, należy dodać kolejne hosty, usługi i nazwy DNS. 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. Podczas migracji stare reguły wyłącza się tylko wtedy, gdy udokumentowano jednoznaczny sposób powrotu.
Jeśli weryfikacja się nie powiedzie, należy wyłączyć nowe reguły NAT i trasy, przywrócić poprzednią konfigurację tunelu i ponownie przetestować pierwotny ruch lokalny. 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.