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 172.16.20.21 i 172.16.20.22 znajdują się za Firewall 1. Adresy transferowe XFRM to 10.255.255.1/30 i 10.255.255.2/30.

Lokalizacja klientów           Route-based IPsec               Lokalizacja serwerów
192.0.2.0/24  →  xfrm2 10.255.255.2  ⇄  10.255.255.1 xfrm1  →  VIP 198.51.100.10
                                                                        │ DNAT
                                                        ┌───────────────┴───────────────┐
                                                        172.16.20.21:443       172.16.20.22:443

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; 172.16.20.0/24 to przykładowa sieć serwerów.

Zachowanie stanu początkowego

Sprawdzić przetestowany tunel w Site-to-site VPN > IPsec, w tym Gateway type: w tym przykładzie Respond only po stronie serwerów i Initiate the connection po stronie klientów. Nie tworzyć tunelu ponownie ani nie zmieniać jego ról bez weryfikacji. Interfejs XFRM zawsze należy do strefy VPN.

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.

W Network > Interfaces kliknąć pionowy niebieski pasek obok fizycznego interfejsu ustawionego jako Listening interface, aby wyświetlić interfejsy podrzędne. Wybrać xfrm1 lub xfrm2 i zapisać planowany adres transferowy przyciskiem Save; nie zmieniać adresów istniejącego tunelu bez sprawdzenia zmiany.

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 172.16.20.21,172.16.20.22.

Na liście umieszczać wyłącznie serwery udostępniające tę samą publikowaną usługę: lista nie ujednolica routingu ani stanu aplikacji.

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.

Dla trasy statycznej w Routing > Static routes podać sieć docelową, adres XFRM drugiej strony jako bramę i lokalny interfejs XFRM.

Jeśli SD-WAN jest już standardem routingu

Utworzyć bramę w Routing > Gateways > Add: Gateway IP to adres XFRM drugiej strony, a Interface to lokalny interfejs XFRM. Monitoring conditions powinny sprawdzać stale dostępny host za bramą. Odpowiedź ICMP lub TCP nie potwierdza działania HTTPS na obu backendach.

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.

Na firewallu klientów otworzyć Routing > SD-WAN routes > IPv4 > Add: Incoming interface to interfejs po stronie klientów, Source networks Remote-Clients, Destination networks VIP-App, Services HTTPS, a Primary and backup gateways to brama XFRM. Bez Route only through specified gateways SFOS sprawdza pozostałe trasy SD-WAN, a przy braku dopasowania stosuje trasę domyślną.

Trasy SD-WAN są sprawdzane w kolejności na liście. Zależnie od route precedence ustawienie Destination networks: Any może skierować również ruch wewnętrzny do WAN. Umieścić konkretną trasę VIP /32 przed szerszymi trasami. Traffic Count zlicza tylko ruch ze zgodnym źródłem i celem; nie potwierdza obu kierunków ani sprawności backendów.

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 172.16.20.21 i 172.16.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.

SFOS sprawdza reguły NAT od góry do dołu i kończy wyszukiwanie przy pierwszym dopasowaniu.

Tworzenie odpowiedniej reguły firewall

Utworzyć regułę po stronie serwerów w Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule. Any w Destination zones byłoby niepotrzebnie szerokie. Reguły firewall również są sprawdzane od góry do pierwszego dopasowania; po utworzeniu sprawdzić ich pozycję.

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 rejestrowanie ruchu 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

Wyzerować liczniki lub zapisać wartości początkowe, a przed testem zamknąć połączenia keep-alive i pule połączeń. W Diagnostics > Packet capture ograniczyć filtry do klienta, VIP i obu adresów backendów. SD-WAN Traffic Count nie zastępuje kontroli logów aplikacji na każdym serwerze.

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.

Przy opcjonalnym pingowaniu firewalla sprawdzić w obu lokalizacjach Administration > Device access > Ping/Ping6 dla strefy VPN. To uprawnienie dotyczy usługi firewalla, a nie aplikacji za VIP. Włączyć je tylko w razie potrzeby, zapisać poprzedni stan i po teście wycofać uprawnienia przyznane wyłącznie na jego potrzeby; nie otwierać w tym celu dostępu WAN ani innych usług administracyjnych.

Jako środek ostrożności operacyjnej przetestować także awarię i przywrócenie tunelu w zatwierdzonym oknie serwisowym: nowe połączenia do VIP muszą odpowiadać wybranemu planowi awarii, a przy Route only through specified gateways być odrzucane, gdy żaden wskazany gateway nie jest dostępny. Po przywróceniu ponownie sprawdzić oba backendy i trasę powrotną. Po rollbacku sprawdzić także nowe połączenia i pierwotny przepływ aplikacji. Są to testy do wykonania we własnym środowisku, a nie deklarowane tutaj wyniki testów na urządzeniu.

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.

Nowe obiekty IP i bram oraz nowo przydzielone adresy XFRM usuwać dopiero wtedy, gdy Object usage i udokumentowana konfiguracja początkowa nie wykazują zależności.

FAQ