Przekazywanie wirtualnego IP przez IPsec do wielu serwerów

Wirtualny IP może wskazywać wiele serwerów wewnętrznych przez istniejący tunel route-based IPsec. Lokalizacja zdalna używa tylko jednego stałego adresu docelowego. Sophos Firewall kieruje ruch przez interfejs XFRM, a następnie za pomocą DNAT tłumaczy adres wirtualny na listę serwerów.

Nie jest to zwykły internetowy DNAT: tunel, adresy XFRM, wybrane trasy, reguły VPN i NAT muszą działać na obu firewallach jako jedna wspólna ścieżka.

Skrócony przebieg

1. Przetestować na obu firewallach tunel route-based Any-to-Any z adresowanymi interfejsami XFRM.
2. Jeśli używany jest SD-WAN, na każdym firewallu utworzyć gateway do adresu XFRM peera.
3. Skierować VIP-App (198.51.100.10/32) i sieć klientów do XFRM trasami statycznymi, dynamicznymi lub SD-WAN zgodnie z istniejącą architekturą.
4. Utworzyć precyzyjne reguły firewalla dla zdalnego źródła, wirtualnego IP i wymaganego serwisu.
5. Po stronie serwerów utworzyć regułę DNAT z wirtualnego IP na listę serwerów z metodą Round-robin.
6. Sprawdzić kilka nowych połączeń za pomocą Log Viewer, Rule IDs, NAT Rule ID i Packet Capture.

⚠️ Zielone połączenie IPsec lub aktywny gateway XFRM nie dowodzą jeszcze, że DNAT i trasa powrotna działają. Najpierw wykonać backup konfiguracji i udokumentować stan początkowy. Przed zmianą produkcyjną rzeczywisty przepływ aplikacji musi być możliwy do prześledzenia w obu kierunkach.

Kiedy ten projekt jest odpowiedni

Ten przebieg jest odpowiedni, gdy hosty w lokalizacji zdalnej muszą uzyskać dostęp do usługi wewnętrznej przez stały adres wirtualny, a rzeczywiste adresy serwerów mają pozostać ukryte. Lista serwerów może na przykład rozdzielać nowe połączenia między dwa równorzędne serwery aplikacyjne.

W przypadku pojedynczego bezpośredniego połączenia do znanego serwera zwykle wystarczy normalna trasa i reguła firewalla. Jeżeli usługa ma być publikowana w Internecie, należy zamiast tego użyć klasycznej procedury DNAT lub WAF. Ogólne planowanie tunelu opisano w artykule Konfiguracja VPN IPsec Site-to-Site.

Ta konkretna procedura wymaga tunelu route-based z Any jako siecią lokalną i zdalną, adresowanych interfejsów XFRM oraz jawnego routingu. Tunel route-based z Traffic Selectors może realizować ten sam cel, ale SFOS tworzy trasy na podstawie selektorów, więc kroki dotyczące gatewayów XFRM nie mają zastosowania bez zmian. Procedura nie dotyczy policy-based IPsec.

Topologia przykładowa

W przykładzie klienci z 192.0.2.0/24 uzyskują dostęp do adresu wirtualnego 198.51.100.10. Serwery 10.0.20.21 i 10.0.20.22 znajdują się za Firewall 1. Adresy transferowe XFRM to 10.255.255.1/30 i 10.255.255.2/30.

Remote clients                 Route-based IPsec                 Server site
192.0.2.0/24  →  xfrm2 10.255.255.2  ⇄  10.255.255.1 xfrm1  →  VIP 198.51.100.10
                                                                        │ DNAT
                                                        ┌───────────────┴───────────────┐
                                                        10.0.20.21           10.0.20.22

Wszystkie adresy są przykładowe i trzeba je zastąpić rzeczywistymi sieciami. Adresy XFRM muszą tworzyć osobną sieć transferową, która nie jest używana nigdzie indziej. Wirtualny IP nie może kolidować z rzeczywistym hostem, interfejsem, siecią VPN ani inną publikacją NAT.

W przykładzie adresy klientów pozostają widoczne dzięki Translated source (SNAT): Original. Oba backendy muszą więc mieć trasę powrotną do 192.0.2.0/24 przez firewall serwerów. Jeśli nie jest to możliwe, może być potrzebny świadomie zaplanowany SNAT; ukrywa on adres klienta i nie jest ogólną naprawą błędnego routingu.

192.0.2.0/24 i 198.51.100.0/24 są sieciami dokumentacyjnymi; 10.0.20.0/24 to przykładowa sieć serwerów.

Zachowanie stanu początkowego

Przed zmianą należy utworzyć backup konfiguracji i zapisać stan IPsec, adresy XFRM, kolejność routingu i SD-WAN, Rule ID reguł firewall i NAT, istniejące liczniki oraz bramy domyślne backendów. Istniejących sesji nie należy używać jako testu.

Tworzenie obiektów IP

Na firewallu serwerów otworzyć Hosts and services > IP host > Add. Utworzyć VIP-App z IP version IPv4, Type IP i adresem wirtualnym oraz Remote-Clients z Type Network. Utworzyć App-Backends z Type IP list i adresami serwerów rozdzielonymi przecinkami. W SFOS 22 IP list mieści do 800 adresów i nie może należeć do IP host group. Listę wykorzystuje się bezpośrednio jako Translated destination (DNAT).

Konkretne wartości obiektów w przykładzie to:

• VIP-App: IP version IPv4, Type IP, IP address 198.51.100.10.
• Remote-Clients: Type Network, IP address 192.0.2.0, Subnet /24.
• App-Backends: IP version IPv4, Type IP list, IP addresses 10.0.20.21,10.0.20.22.

Definiowanie tras tunelu

Poniższe trasy SD-WAN są potrzebne tylko wtedy, gdy SD-WAN jest już wybraną metodą routingu. Tunel Any-to-Any może używać także tras statycznych lub dynamicznych: po stronie klienta skierować VIP-App (198.51.100.10/32) do XFRM, a po stronie serwerów Remote-Clients do XFRM. Nie wyprowadzać ani nie dublować tras bez sprawdzenia istniejącej route precedence.

Na Firewall 1 tunel tworzy się jako Route-based (Tunnel interface) z Respond only; na Firewall 2 używa się Initiate the connection. Po obu stronach Local subnet i Remote subnet ustawia się na Any.

Następnie interfejsom XFRM przypisuje się adresy transferowe w Network > Interfaces:

• Firewall 1, xfrm1: 10.255.255.1/30
• Firewall 2, xfrm2: 10.255.255.2/30

Parametry Phase 1 i Phase 2, IDs oraz uwierzytelnianie muszą być wcześniej przetestowane. Nie zmienia się adresów XFRM w nieprzetestowanym tunelu produkcyjnym.

Jeśli SD-WAN jest już standardem routingu

Każdy firewall potrzebuje gatewaya do adresu XFRM peera dla tras SD-WAN:

• Firewall 1: Gateway IP 10.255.255.2 przez xfrm1
• Firewall 2: Gateway IP 10.255.255.1 przez xfrm2

Status gatewaya sprawdza tylko wybrany Monitoring Target. Artykuł Tworzenie i sprawdzanie Custom Gateway szczegółowo wyjaśnia obiekt, Health Check i test funkcjonalny.

Trasa SD-WAN na Firewall 2 kieruje ruch z 192.0.2.0/24 do 198.51.100.10 przez gateway XFRM. Route only through specified gateways zapobiega przejściu inną trasą, gdy usługa ma być dostępna wyłącznie przez ten tunel.

Decyzja o tej opcji należy do planu awarii. Bez niej ruch może przejąć inna trasa; z włączoną opcją SFOS odrzuca ruch, gdy wskazany gateway jest niedostępny. Tworzenie i testowanie trasy SD-WAN opisuje pełną konfigurację.

Firewall 1 musi mieć skuteczną trasę do 192.0.2.0/24 przez XFRM. Nie zakładać, że lustrzana trasa SD-WAN obsłuży odpowiedzi: trasy SD-WAN dotyczą reply packets tylko po włączeniu set routing sd-wan-policy-route reply-packet enable. Sprawdzić to ustawienie globalne albo użyć istniejącego routingu statycznego lub dynamicznego.

Translacja wirtualnego IP na listę serwerów przez DNAT

Na Firewall 1 tworzy się precyzyjną regułę w Rules and policies > NAT rules > Add NAT rule > New NAT rule:

• Rule name: DNAT-VPN-VIP-App
• Rule position: nad szerszymi regułami NAT, które również mogą pasować
• Original source: 192.0.2.0/24
• Translated source: Original
• Original destination: 198.51.100.10
• Original service: rzeczywista usługa aplikacji, na przykład HTTPS
• Translated destination: obiekt listy serwerów z 10.0.20.21 i 10.0.20.22
• Translated service: Original
• Inbound interface / Outbound interface: Any (wymagane w polach NAT dla ruchu VPN)
• Load balancing method: Round robin
• Health check: włączony, Probe method TCP, Port 443

DNAT sam w sobie nie zezwala na ruch. Reguła firewalla, wybrana trasa tunelu i trasa powrotna pozostają osobnymi wymaganiami. Zrozumienie NAT w Sophos Firewall wyjaśnia wartości oryginalne i przetłumaczone oraz kolejność reguł.

Round-robin rozdziela nowe pasujące połączenia między członków listy serwerów. Ponownie używany kanał przeglądarki lub aplikacji nie jest więc prawidłowym testem rozkładu. Metoda wyboru nie potwierdza też automatycznie stanu aplikacji na każdym backendzie. Oba serwery testuje się osobno za pomocą nowych sesji.

Round robin wysyła nowe żądania kolejno do członków. Bez Health check SFOS uznaje wszystkie elementy za dostępne i może wybrać niedziałający serwer. Ustawić Probe interval, Response time-out i Deactivate host after; sonda TCP nie zastępuje testu aplikacji. NAT dotyczy tylko pierwszego pakietu: zmiana nie przenosi istniejących sesji i wymaga nowych połączeń testowych.

Tworzenie odpowiedniej reguły firewall

Reguła wychodząca używa LAN jako Source zone i VPN jako Destination zone. Źródłem jest 192.0.2.0/24, celem 198.51.100.10, usługa odpowiada aplikacji, a logowanie pozostaje włączone podczas wdrożenia.

Przychodząca reguła firewalla zezwala tylko na planowany przepływ danych:

• Rule name: Allow-VPN-VIP-App
• Rule position: nad nakładającymi się regułami
• Action: Accept
• Source zone: VPN
• Source networks and devices: 192.0.2.0/24
• Destination zone: strefa przetłumaczonych backendów, w tym przykładzie LAN
• Destination networks: tylko 198.51.100.10
• Services: tylko usługa aplikacji, na przykład HTTPS
• Log firewall traffic: włączone

SFOS najpierw wyszukuje DNAT, a następnie używa w regule firewalla strefy przetłumaczonego celu. Destination networks pozostaje pierwotnym VIP. Pozycję i Rule ID sprawdzić rzeczywistym ruchem.

Test całej ścieżki

Przed testem dokumentuje się status tunelu, adresy XFRM, status gatewayów, pozycje tras SD-WAN i Rule IDs. Następnie tworzy się kilka nowych połączeń aplikacyjnych z sieci zdalnej do wirtualnego IP.

W Log Viewer sprawdzić źródło, oczekiwaną Firewall Rule ID i NAT Rule ID. VIP przed NAT i przetłumaczony backend porównać za pomocą precyzyjnego Packet Capture; nie wnioskować o translacji z niejednoznacznego pola celu. Zrzut pokazuje też wejście przez XFRM i powrót przez ten sam firewall.

Test powtarza się z oboma backendami. Na serwerach muszą zgadzać się oczekiwany adres klienta, usługa i trasa powrotna. Ping do wirtualnego IP nie zastępuje rzeczywistego testu HTTPS, SAP ani innej aplikacji.

Testowanie reguły firewalla za pomocą Log Viewer i Packet Capture pomaga we wspólnej kontroli reguły, NAT i ścieżki pakietów.

Systematyczne zawężanie błędów

Brak NAT Rule ID

Sprawdzić Original source, VIP-App, HTTPS i pozycję reguły NAT. Sprawdzić również, czy wcześniejsza reguła NAT nie pasuje jako pierwsza. Po korekcie utworzyć nowe połączenie, ponieważ istniejące sesje nie są ponownie oceniane przez NAT.

DNAT pasuje, ale reguła firewall nie

Destination zones muszą odpowiadać strefie przetłumaczonych adresów backendów, a nie VIP ani ogólnie VPN. Destination networks pozostaje VIP-App. Następnie ponownie sprawdzić Rule ID i zdarzenie odrzucenia w Log Viewer.

Jeden backend pozostaje nieosiągalny

Porównać stan Health Check, metodę probe i port z rzeczywistą usługą. Bez Health Check SFOS może wybrać niedziałający element. Nawet udany probe TCP nie sprawdza aplikacji, TLS ani autoryzacji; przetestować backend bezpośrednio w sieci serwerów, a następnie przez nową sesję VIP.

Odpowiedź korzysta z niewłaściwej trasy

Sprawdzić bramę domyślną lub konkretną trasę backendu, trasę do Remote-Clients i Packet Capture na firewallu serwerów. Nie dodawać szerokiej reguły MASQ jako skrótu diagnostycznego. Dla SD-WAN sprawdzić też pozycję, route precedence, monitoring i Route only through specified gateways.

Bezpieczny rollback

Najpierw wyłączyć DNAT, aby zatrzymać nowe sesje, a istniejące pozostawić do wygaśnięcia lub zakończyć w oknie serwisowym. Zmiany NAT nie są ponownie oceniane dla zestawionego połączenia. Następnie wyłączyć tylko reguły i trasy utworzone dla tej ścieżki i odtworzyć udokumentowaną kolejność.

Przed zmianą dokumentuje się backup konfiguracji, stan tunelu, adresy XFRM, obiekty gateway, reguły i trasy. Jeśli nowa ścieżka nie działa:

1. Wyłączyć nową regułę DNAT.
2. Wyłączyć tylko trasy statyczne lub SD-WAN utworzone dla tej ścieżki.
3. Przywrócić konkretne reguły firewalla do poprzedniego stanu.
4. Usunąć tylko nowe gatewaye i nowo przypisane adresy XFRM, gdy nie ma zależności.
5. Ponownie przetestować pierwotny tunel i przepływ aplikacji.

Nie usuwać gatewaya, dopóki Object usage wskazuje zależności. Interfejs XFRM jest tworzony przez tunel; nie usuwać istniejącego tunelu przenoszącego inne sieci. Backup i przywracanie Sophos Firewall wyjaśnia bezpieczny proces tworzenia kopii i odzyskiwania.

FAQ