Vidarebefordra ett virtuellt IP via IPsec till flera servrar

Ett virtuellt IP kan peka på flera interna servrar genom en befintlig ruttbaserad IPsec-tunnel. Fjärrplatsen använder bara en stabil destinationsadress. Sophos Firewall routar trafiken via XFRM-gränssnittet och översätter därefter den virtuella adressen till en serverlista med DNAT.

Detta är inte vanlig DNAT från internet: tunnel, XFRM-adresser, valda rutter, VPN-regler och NAT måste fungera som en gemensam sökväg på båda brandväggarna.

Kort arbetsgång

1. Verifiera en ruttbaserad Any-to-Any-tunnel med adresserade XFRM-gränssnitt på båda brandväggarna.
2. Om SD-WAN används skapar du på varje brandvägg en gateway till motpartens XFRM-adress.
3. Dirigera VIP /32 och klientnätet till XFRM med statiska, dynamiska eller SD-WAN-rutter enligt befintlig arkitektur.
4. Skapa snäva brandväggsregler för fjärrkällan, det virtuella IP-numret och den tjänst som behövs.
5. Skapa på serversidan en DNAT-regel från det virtuella IP-numret till en serverlista med Round-robin.
6. Kontrollera flera nya anslutningar med Log Viewer, Rule IDs, NAT Rule ID och Packet Capture.

⚠️ En grön IPsec-anslutning eller aktiv XFRM-gateway bevisar ännu inte att DNAT och returvägen fungerar. Skapa först en konfigurationsbackup och dokumentera utgångsläget. Före produktionsändringen måste det verkliga applikationsflödet kunna följas i båda riktningarna.

När den här designen passar

Arbetsgången passar när värdar på en fjärrplats ska nå en intern tjänst via en fast virtuell adress, medan de verkliga serveradresserna förblir dolda. En serverlista kan till exempel fördela nya anslutningar mellan två likvärdiga applikationsservrar.

För en enda direktanslutning till en känd server räcker normalt en vanlig rutt och en brandväggsregel. Om en tjänst ska publiceras på internet används i stället den vanliga DNAT- eller WAF-arbetsgången. Den allmänna tunnelplaneringen finns i Konfigurera en Site-to-Site IPsec VPN.

Den här specifika proceduren kräver en ruttbaserad tunnel med Any som lokalt nät och fjärrnät, adresserade XFRM-gränssnitt och explicit routning. En ruttbaserad tunnel med Traffic Selectors kan uppnå samma mål, men SFOS skapar då rutterna från selektorerna; stegen för XFRM-gateway gäller därför inte oförändrade. Proceduren gäller inte policybaserad IPsec.

Exempeltopologi

I exemplet ansluter klienter från 192.0.2.0/24 till den virtuella adressen 198.51.100.10. Servrarna 10.0.20.21 och 10.0.20.22 finns bakom Firewall 1. XFRM-överföringsadresserna är 10.255.255.1/30 och 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

Alla adresser är exempelvärden och ersätts med de verkliga näten. XFRM-adresserna måste bilda ett eget överföringsnät som inte används någon annanstans. Det virtuella IP-numret får inte överlappa en verklig värd, ett gränssnitt, ett VPN-nät eller en annan NAT-publicering.

Exemplet bevarar klientadresserna med Translated source (SNAT): Original. Båda backendservrarna behöver därför en returväg till 192.0.2.0/24 via serverbrandväggen. Om detta inte går kan planerad SNAT krävas; den döljer klientadressen och är ingen allmän lösning på felaktig routing.

192.0.2.0/24 och 198.51.100.0/24 är dokumentationsnät; 10.0.20.0/24 är servernätet i exemplet.

Bevara utgångsläget

Skapa en konfigurationsbackup före ändringen och dokumentera IPsec-status, XFRM-adresser, ordningen för routing och SD-WAN, Rule ID för brandvägg och NAT, befintliga räknare samt backendservrarnas standardgateway. Använd inte redan etablerade sessioner som test.

Skapa IP-objekten

Öppna Hosts and services > IP host > Add på serverbrandväggen. Skapa VIP-App med IP version IPv4, Type IP och den virtuella adressen samt Remote-Clients med Type Network. Skapa App-Backends med Type IP list och kommaseparerade serveradresser. I SFOS 22 rymmer en IP list högst 800 adresser och kan inte ingå i en IP host group. Använd listan direkt som Translated destination (DNAT).

De konkreta objektvärdena i exemplet är:

• 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.

Definiera tunnelrutterna

Följande SD-WAN-rutter behövs bara om SD-WAN redan är vald dirigeringsmetod. En Any-to-Any-tunnel kan även använda statiska eller dynamiska rutter: dirigera VIP-App (198.51.100.10/32) till XFRM på klientsidan och Remote-Clients till XFRM på serversidan. Härled eller duplicera inte rutter utan att kontrollera befintlig route precedence.

På Firewall 1 skapas tunneln som Route-based (Tunnel interface) med Respond only; på Firewall 2 används Initiate the connection. På båda sidor ställs Local subnet och Remote subnet in på Any.

Därefter tilldelas XFRM-gränssnitten sina överföringsadresser under Network > Interfaces:

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

Parametrarna för Phase 1 och Phase 2, IDs och autentiseringen måste redan vara verifierade. Ändra inte XFRM-adresser på en oprövad produktionstunnel.

Om SD-WAN redan är routingstandard

För SD-WAN-rutterna behöver varje brandvägg en gateway till motpartens XFRM-adress:

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

Gatewaystatusen kontrollerar endast valt Monitoring Target. Skapa och verifiera en Custom Gateway förklarar objektet, Health Check och funktionstestet fullständigt.

SD-WAN-rutten på Firewall 2 skickar trafik från 192.0.2.0/24 till 198.51.100.10 via XFRM-gatewayen. Route only through specified gateways förhindrar en alternativ sökväg via en annan rutt när tjänsten endast får nås genom denna tunnel.

Om alternativet är önskvärt hör hemma i avbrottsplanen. Utan det kan en annan rutt ta över; med alternativet aktivt kasserar SFOS trafiken när angiven gateway inte är tillgänglig. Skapa och testa en SD-WAN-rutt förklarar hela konfigurationen.

Firewall 1 måste ha en fungerande rutt till 192.0.2.0/24 via XFRM. Anta inte att en speglad SD-WAN-rutt hanterar svar: SD-WAN-rutter gäller reply packets endast när set routing sd-wan-policy-route reply-packet enable är aktiverat. Kontrollera denna globala inställning eller använd befintlig statisk eller dynamisk routning.

Översätt det virtuella IP-numret till serverlistan med DNAT

På Firewall 1 skapas en riktad regel under Rules and policies > NAT rules > Add NAT rule > New NAT rule:

• Rule name: DNAT-VPN-VIP-App
• Rule position: ovanför bredare NAT-regler som också kan matcha
• Original source: 192.0.2.0/24
• Translated source: Original
• Original destination: 198.51.100.10
• Original service: den verkliga applikationstjänsten, till exempel HTTPS
• Translated destination: serverlisteobjekt med 10.0.20.21 och 10.0.20.22
• Translated service: Original
• Inbound interface / Outbound interface: Any (obligatoriskt i NAT-fälten för VPN-trafik)
• Load balancing method: Round robin
• Health check: aktiverad, Probe method TCP, Port 443

DNAT tillåter ingen trafik på egen hand. Brandväggsregel, vald tunnelrutt och returväg är fortfarande separata krav. Förstå NAT på Sophos Firewall förklarar ursprungliga och översatta värden samt regelordningen.

Round-robin fördelar nya matchande anslutningar mellan medlemmarna i serverlistan. En återanvänd webbläsar- eller applikationskanal är därför inget giltigt fördelningstest. Valmetoden bevisar inte heller automatiskt applikationens hälsa på varje backend. Testa båda servrarna separat med nya sessioner.

Round robin skickar nya förfrågningar till medlemmarna i turordning. Utan Health check betraktar SFOS alla medlemmar som tillgängliga och kan välja en server som är nere. Ange Probe interval, Response time-out och Deactivate host after; en TCP-probe ersätter inte ett applikationstest. NAT gäller bara det första paketet: ändringar flyttar inte etablerade sessioner och måste testas med nya anslutningar.

Skapa den matchande brandväggsregeln

Den utgående regeln använder LAN som Source zone och VPN som Destination zone. Källan är 192.0.2.0/24, målet är 198.51.100.10, tjänsten motsvarar applikationen och loggning förblir aktiverad under införandet.

Den inkommande brandväggsregeln tillåter endast det planerade dataflödet:

• Rule name: Allow-VPN-VIP-App
• Rule position: ovanför överlappande regler
• Action: Accept
• Source zone: VPN
• Source networks and devices: 192.0.2.0/24
• Destination zone: zonen för översatta backendservrar, LAN i exemplet
• Destination networks: endast 198.51.100.10
• Services: endast applikationstjänsten, till exempel HTTPS
• Log firewall traffic: aktiverad

SFOS söker först DNAT och använder sedan zonen för den översatta destinationen i brandväggsregeln. Destination networks är fortfarande ursprunglig VIP. Kontrollera position och Rule ID med verklig trafik.

Verifiera hela sökvägen

Före testet dokumenteras tunnelstatus, XFRM-adresser, gatewaystatus, SD-WAN-rutternas position och Rule IDs. Därefter skapas flera nya applikationsanslutningar från fjärrnätet till det virtuella IP-numret.

Kontrollera källa, förväntat Firewall Rule ID och NAT Rule ID i Log Viewer. Jämför VIP före NAT med översatt backend i en snäv Packet Capture; dra inte slutsats om översättningen från ett tvetydigt destinationsfält. Infångningen visar också ankomst via XFRM och retur genom samma brandvägg.

Testet upprepas med båda backends. På servrarna måste förväntad klientadress, tjänst och returväg stämma. Ett ping till det virtuella IP-numret ersätter inte ett verkligt HTTPS-, SAP- eller annat applikationstest.

Testa en brandväggsregel med Log Viewer och Packet Capture hjälper vid den kombinerade kontrollen av regel, NAT och paketväg.

Avgränsa fel systematiskt

Inget NAT Rule ID

Kontrollera Original source, VIP-App, HTTPS och NAT-regelns position. Kontrollera även om en tidigare NAT-regel matchar först. Skapa en ny anslutning efter en korrigering, eftersom befintliga sessioner inte utvärderas på nytt av NAT.

DNAT matchar, men brandväggsregeln gör det inte

Destination zones måste motsvara zonen för de översatta backendadresserna, inte VIP-adressen och inte generellt VPN. Destination networks förblir VIP-App. Kontrollera sedan Rule ID och blockeringshändelsen i Log Viewer igen.

En backend är fortfarande oåtkomlig

Jämför Health Check-status, probemetod och port med den verkliga tjänsten. Utan Health Check kan SFOS välja en server som ligger nere. Inte heller en lyckad TCP-probe validerar programmet, TLS eller behörigheten; testa servern direkt i servernätet och därefter via en ny VIP-session.

Svaret tar fel väg

Kontrollera serverns standardgateway eller specifika rutt, rutten till Remote-Clients och Packet Capture på serverbrandväggen. Lägg inte till en bred MASQ-regel som diagnostisk genväg. Kontrollera för SD-WAN även position, route precedence, monitoring och Route only through specified gateways.

Återställ säkert

Inaktivera först DNAT för att stoppa nya sessioner och låt sedan befintliga sessioner löpa ut eller avsluta dem i underhållsfönstret. NAT-ändringar utvärderas inte på nytt för en etablerad anslutning. Inaktivera därefter endast regler och rutter som skapats för sökvägen och återställ dokumenterad ordning.

Före ändringen dokumenteras konfigurationsbackup, tunnelstatus, XFRM-adresser, gatewayobjekt, regler och rutter. Om den nya sökvägen inte fungerar:

1. Inaktivera den nya DNAT-regeln.
2. Inaktivera endast statiska rutter eller SD-WAN-rutter som skapades för den här sökvägen.
3. Återställ de specifika brandväggsreglerna till föregående läge.
4. Ta endast bort nya gateways och nytilldelade XFRM-adresser när inga beroenden finns.
5. Testa ursprunglig tunnel och ursprungligt applikationsflöde igen.

Ta inte bort en gateway så länge Object usage visar beroenden. XFRM-gränssnittet skapas av tunneln; ta inte bort en befintlig tunnel som transporterar andra nät. Backup och återställning av Sophos Firewall beskriver den säkra processen.

FAQ