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, trasy SD-WAN, 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. Utworzyć gateway dla każdego adresu XFRM peera.
3. Skonfigurować lustrzane trasy SD-WAN dla sieci zdalnej, sieci lokalnych i wirtualnego IP.
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ą. 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.

Ten projekt nie nadaje się do policy-based IPsec ani tuneli route-based z konkretnymi Traffic Selectors. Opisana ścieżka wymaga tunelu route-based z Any jako siecią lokalną i zdalną, adresowanych interfejsów XFRM oraz jawnego routingu.

Topologia przykładowa

W przykładzie klienci z 192.168.3.0/24 uzyskują dostęp do adresu wirtualnego 10.10.10.1. Serwery 172.16.16.2 i 172.16.16.3 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.168.3.0/24  →  xfrm2 10.255.255.2  ⇄  10.255.255.1 xfrm1  →  VIP 10.10.10.1
                                                                        │ DNAT
                                                        ┌───────────────┴───────────────┐
                                                        172.16.16.2           172.16.16.3

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.

Przygotowanie tunelu i XFRM

Tunel Any-to-Any i adresy transferowe

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.

Tworzenie gatewayów XFRM

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.

Tworzenie reguł i tras SD-WAN

Firewall 1 po stronie serwerów

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

• Source zone: VPN
• Source networks and devices: 192.168.3.0/24
• Destination zone: Any, jak w przykładzie Sophos dla adresu wirtualnego
• Destination networks: 10.10.10.1 i inne sieci lokalne tylko w razie potrzeby
• Services: tylko usługa aplikacji, na przykład HTTPS
• Log firewall traffic: włączone

Any w Destination zone nie uzasadnia szerokich źródeł, celów ani usług. Wirtualny IP nie jest przypisany do normalnego interfejsu. Dlatego Rule ID trzeba potwierdzić rzeczywistym ruchem.

Trasa SD-WAN na Firewall 1 kieruje ruch powrotny do sieci zdalnej przez gateway XFRM. Jako Source networks podaje się rzeczywiście potrzebne sieci lokalne i 10.10.10.1, a jako Destination networks — 192.168.3.0/24.

Firewall 2 w lokalizacji zdalnej

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

Trasa SD-WAN na Firewall 2 kieruje ruch z 192.168.3.0/24 do 10.10.10.1 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ę.

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:

• Original source: 192.168.3.0/24
• Translated source: Original
• Original destination: 10.10.10.1
• Original service: rzeczywista usługa aplikacji, na przykład HTTPS
• Translated destination: obiekt listy serwerów z 172.16.16.2 i 172.16.16.3
• Translated service: Original
• Load balancing method: Round-robin

DNAT sam w sobie nie zezwala na ruch. Reguła firewalla, trasa SD-WAN 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.

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 muszą być widoczne źródło 192.168.3.0/24, cel 10.10.10.1, oczekiwana Firewall Rule ID i NAT Rule ID. Traffic Count trasy SD-WAN musi wzrastać. Precyzyjny Packet Capture pokazuje, czy pakiety docierają przez interfejs XFRM, są po DNAT wysyłane do wybranego serwera i wracają tym samym tunelem.

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

Tunel jest zielony, ale wirtualny IP nie odpowiada

Najpierw sprawdzić trasę SD-WAN na Firewall 2: czy zgadzają się źródło, cel, usługa i gateway XFRM? Następnie sprawdzić Rule ID i NAT Rule ID na Firewall 1. Brak NAT Rule ID oznacza, że nie zgadzają się Original source, Original destination, usługa lub pozycja reguły.

DNAT pasuje, ale serwer nie odpowiada

Sprawdzić obiekt listy serwerów, lokalną usługę i gateway serwera. Trasa powrotna musi prowadzić przez Firewall 1, aby istniejąca sesja NAT przetłumaczyła odpowiedź z powrotem na 10.10.10.1. Nie dodawać szerokiej reguły MASQ jako skrótu, ponieważ może zafałszować diagnozę.

Tylko jeden serwer otrzymuje połączenia

Użyć kilku rzeczywiście nowych sesji i zamknąć istniejące połączenia Keep-alive. Następnie porównać listę serwerów, Load balancing method i NAT Rule ID. Jeżeli jeden backend nie działa bezpośrednio, najpierw naprawić jego usługę lub ścieżkę lokalną.

Ruch korzysta z innej trasy

Sprawdzić pozycję i Traffic Count tras SD-WAN oraz wybrane gatewaye XFRM. Policy Tester nie uwzględnia w pełni tras SD-WAN; należy użyć łącznie Log Viewer, Route lookup i Packet Capture.

Bezpieczny rollback

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ć dwie nowe trasy SD-WAN.
3. Przywrócić konkretne reguły firewalla do poprzedniego stanu.
4. Usunąć gatewaye XFRM i adresy transferowe tylko wtedy, gdy nie używa ich żadna inna trasa.
5. Ponownie przetestować pierwotny tunel i przepływ aplikacji.

Nie usuwać gatewaya ani interfejsu XFRM, dopóki Object usage wskazuje zależności. Backup i przywracanie Sophos Firewall wyjaśnia bezpieczny proces tworzenia kopii i odzyskiwania.

FAQ