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, SD-WAN-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. Skapa en gateway för varje XFRM-adress hos motparten.
3. Konfigurera spegelvända SD-WAN-rutter för fjärrnätet, de lokala näten och det virtuella IP-numret.
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. 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.

Designen passar inte policybaserad IPsec eller ruttbaserade tunnlar med specifika Traffic Selectors. Den beskrivna sökvägen kräver en ruttbaserad tunnel med Any som lokalt nät och fjärrnät, adresserade XFRM-gränssnitt och explicit routning.

Exempeltopologi

I exemplet ansluter klienter från 192.168.3.0/24 till den virtuella adressen 10.10.10.1. Servrarna 172.16.16.2 och 172.16.16.3 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.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

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.

Förbered tunneln och XFRM

Any-to-Any-tunnel och överföringsadresser

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.

Skapa XFRM-gateways

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.

Bygg regler och SD-WAN-rutter

Firewall 1 på serverplatsen

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

• Source zone: VPN
• Source networks and devices: 192.168.3.0/24
• Destination zone: Any, som i Sophos-exemplet för den virtuella adressen
• Destination networks: 10.10.10.1 och andra lokala nät endast vid behov
• Services: endast applikationstjänsten, till exempel HTTPS
• Log firewall traffic: aktiverad

Any i Destination zone är inget skäl för breda källor, mål eller tjänster. Det virtuella IP-numret är inte tilldelat ett normalt gränssnitt. Därför måste Rule ID bekräftas med verklig trafik.

SD-WAN-rutten på Firewall 1 skickar returtrafiken till fjärrnätet via XFRM-gatewayen. Som Source networks anges de lokala nät som faktiskt behövs och 10.10.10.1; som Destination networks anges 192.168.3.0/24.

Firewall 2 på fjärrplatsen

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

SD-WAN-rutten på Firewall 2 skickar trafik från 192.168.3.0/24 till 10.10.10.1 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.

Ö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:

• Original source: 192.168.3.0/24
• Translated source: Original
• Original destination: 10.10.10.1
• Original service: den verkliga applikationstjänsten, till exempel HTTPS
• Translated destination: serverlisteobjekt med 172.16.16.2 och 172.16.16.3
• Translated service: Original
• Load balancing method: Round-robin

DNAT tillåter ingen trafik på egen hand. Brandväggsregel, SD-WAN-rutt 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.

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.

I Log Viewer måste källan 192.168.3.0/24, målet 10.10.10.1, förväntad Firewall Rule ID och NAT Rule ID synas. Traffic Count för SD-WAN-rutten måste öka. En snäv Packet Capture visar om paketen anländer till XFRM-gränssnittet, skickas till vald server efter DNAT och återvänder genom samma tunnel.

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

Tunneln är grön, men det virtuella IP-numret svarar inte

Kontrollera först SD-WAN-rutten på Firewall 2: matchar källa, mål, tjänst och XFRM-gateway? Kontrollera sedan Rule ID och NAT Rule ID på Firewall 1. Om NAT Rule ID saknas matchar inte Original source, Original destination, tjänsten eller regelpositionen.

DNAT matchar, men servern svarar inte

Kontrollera serverlisteobjektet, den lokala servertjänsten och serverns gateway. Returvägen måste gå via Firewall 1 så att den befintliga NAT-sessionen kan översätta svaret tillbaka till 10.10.10.1. Lägg inte till en bred MASQ-regel som genväg, eftersom det kan förvränga diagnosen.

Endast en server tar emot anslutningar

Använd flera verkligt nya sessioner och stäng befintliga Keep-alive-anslutningar. Jämför sedan serverlistan, Load balancing method och NAT Rule ID. Om en backend inte fungerar direkt repareras först dess tjänst eller lokala sökväg.

Trafiken tar en annan rutt

Kontrollera SD-WAN-rutternas position och Traffic Count samt valda XFRM-gateways. Policy Tester tar inte full hänsyn till SD-WAN-rutter; använd Log Viewer, Route lookup och Packet Capture tillsammans.

Återställ säkert

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 de två nya SD-WAN-rutterna.
3. Återställ de specifika brandväggsreglerna till föregående läge.
4. Ta endast bort XFRM-gateways och överföringsadresser om ingen annan rutt använder dem.
5. Testa ursprunglig tunnel och ursprungligt applikationsflöde igen.

Ta inte bort en gateway eller ett XFRM-gränssnitt så länge Object usage fortfarande visar beroenden. Backup och återställning av Sophos Firewall förklarar den säkra processen för backup och återställning.

FAQ