Inoltrare un IP virtuale via IPsec a più server
Un IP virtuale può puntare a più server interni attraverso un tunnel IPsec route-based esistente. La sede remota utilizza un solo indirizzo di destinazione stabile. Sophos Firewall instrada il traffico attraverso l’interfaccia XFRM e poi traduce l’indirizzo virtuale su una server list tramite DNAT.
Non si tratta di un normale DNAT Internet: tunnel, indirizzi XFRM, route SD-WAN, regole VPN e NAT devono funzionare come un unico percorso su entrambi i firewall.
Procedura rapida
- Collaudare un tunnel route-based Any-to-Any con interfacce XFRM indirizzate su entrambi i firewall.
- Creare un gateway per ciascun indirizzo XFRM del peer.
- Configurare route SD-WAN speculari per la rete remota, le reti locali e l’IP virtuale.
- Creare regole firewall ristrette per la sorgente remota, l’IP virtuale e il servizio necessario.
- Sul lato server, creare una regola DNAT dall’IP virtuale a una server list con Round-robin.
- Verificare più nuove connessioni con Log Viewer, Rule IDs, NAT Rule ID e Packet Capture.
⚠️ Una connessione IPsec verde o un gateway XFRM attivo non dimostrano ancora che DNAT e percorso di ritorno funzionino. Prima del passaggio in produzione deve essere possibile seguire il flusso applicativo reale in entrambe le direzioni.
Quando è adatto questo design
La procedura è adatta quando gli host di una sede remota devono raggiungere un servizio interno tramite un indirizzo virtuale fisso, mentre gli indirizzi reali dei server restano nascosti. Una server list può ad esempio distribuire le nuove connessioni tra due application server equivalenti.
Per una singola connessione diretta a un server noto è generalmente sufficiente una route normale con una regola firewall. Se un servizio deve essere pubblicato su Internet, si utilizza invece il normale percorso DNAT o WAF. La pianificazione generale del tunnel è descritta in Configurare una VPN IPsec Site-to-Site.
Questo design non è adatto a IPsec policy-based o a tunnel route-based con Traffic Selectors specifici. Il percorso descritto richiede un tunnel route-based con Any come rete locale e remota, interfacce XFRM indirizzate e routing esplicito.
Topologia di esempio
Nell’esempio, i client di 192.168.3.0/24 accedono all’indirizzo virtuale 10.10.10.1. I server 172.16.16.2 e 172.16.16.3 si trovano dietro Firewall 1. Gli indirizzi di trasferimento XFRM sono 10.255.255.1/30 e 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
Tutti gli indirizzi sono valori di esempio e devono essere sostituiti con le reti reali. Gli indirizzi XFRM devono formare una rete di trasferimento dedicata non utilizzata altrove. L’IP virtuale non deve sovrapporsi a un host reale, un’interfaccia, una rete VPN o un’altra pubblicazione NAT.
Preparare tunnel e XFRM
Tunnel Any-to-Any e indirizzi di trasferimento
Su Firewall 1 il tunnel viene creato come Route-based (Tunnel interface) con Respond only; su Firewall 2 si usa Initiate the connection. Su entrambi i lati, Local subnet e Remote subnet sono impostati su Any.
Successivamente si assegnano gli indirizzi di trasferimento alle interfacce XFRM in Network > Interfaces:
- Firewall 1,
xfrm1:10.255.255.1/30 - Firewall 2,
xfrm2:10.255.255.2/30
I parametri di Phase 1 e Phase 2, gli IDs e l’autenticazione devono essere già collaudati. Gli indirizzi XFRM non si modificano su un tunnel di produzione non testato.
Creare i gateway XFRM
Per le route SD-WAN, ogni firewall necessita di un gateway verso l’indirizzo XFRM del peer:
- Firewall 1: Gateway IP
10.255.255.2tramitexfrm1 - Firewall 2: Gateway IP
10.255.255.1tramitexfrm2
Lo stato del gateway verifica soltanto il Monitoring Target selezionato. Creare e verificare un Custom Gateway spiega in modo completo l’oggetto, l’Health Check e il test funzionale.
Creare regole e route SD-WAN
Firewall 1 nella sede dei server
La regola firewall in ingresso consente solo il flusso previsto:
- Source zone:
VPN - Source networks and devices:
192.168.3.0/24 - Destination zone:
Any, come nell’esempio Sophos per l’indirizzo virtuale - Destination networks:
10.10.10.1e altre reti locali solo se necessarie - Services: solo il servizio applicativo, ad esempio
HTTPS - Log firewall traffic: attivato
Any nella Destination zone non giustifica sorgenti, destinazioni o servizi ampi. L’IP virtuale non è assegnato a una normale interfaccia. La Rule ID deve quindi essere confermata con traffico reale.
La route SD-WAN su Firewall 1 inoltra il traffico di ritorno alla rete remota tramite il gateway XFRM. Come Source networks si inseriscono le reti locali effettivamente necessarie e 10.10.10.1; come Destination networks, 192.168.3.0/24.
Firewall 2 nella sede remota
La regola in uscita usa LAN come Source zone e VPN come Destination zone. La sorgente è 192.168.3.0/24, la destinazione è almeno 10.10.10.1, il servizio corrisponde all’applicazione e il logging resta attivo durante l’introduzione.
La route SD-WAN su Firewall 2 inoltra il traffico da 192.168.3.0/24 a 10.10.10.1 tramite il gateway XFRM. Route only through specified gateways impedisce un percorso alternativo attraverso un’altra route quando il servizio deve essere raggiungibile esclusivamente tramite questo tunnel.
La scelta di questa opzione appartiene al piano di guasto. Senza di essa può subentrare un’altra route; con l’opzione attiva, SFOS scarta il traffico quando il gateway specificato non è disponibile. Creare e testare una route SD-WAN descrive la configurazione completa.
Tradurre l’IP virtuale sulla server list tramite DNAT
Su Firewall 1 si crea una regola mirata in 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: il servizio applicativo reale, ad esempio
HTTPS - Translated destination: oggetto server list con
172.16.16.2e172.16.16.3 - Translated service:
Original - Load balancing method:
Round-robin
Il DNAT non consente traffico da solo. La regola firewall, la route SD-WAN e il percorso di ritorno restano requisiti separati. Comprendere il NAT su Sophos Firewall spiega i valori originali e tradotti e l’ordine delle regole.
Round-robin distribuisce le nuove connessioni corrispondenti tra i membri della server list. Un canale browser o applicativo riutilizzato non è quindi un test di distribuzione valido. Il metodo di selezione non dimostra automaticamente nemmeno la salute dell’applicazione su ogni backend. Entrambi i server vengono testati separatamente con nuove sessioni.
Collaudare il percorso completo
Prima del test si documentano stato del tunnel, indirizzi XFRM, stato dei gateway, posizione delle route SD-WAN e Rule IDs. Successivamente si generano più nuove connessioni applicative dalla rete remota verso l’IP virtuale.
Nel Log Viewer devono essere visibili la sorgente 192.168.3.0/24, la destinazione 10.10.10.1, la Firewall Rule ID prevista e la NAT Rule ID. Il Traffic Count della route SD-WAN deve aumentare. Un Packet Capture ristretto mostra se i pacchetti arrivano sull’interfaccia XFRM, vengono inviati al server selezionato dopo il DNAT e ritornano attraverso lo stesso tunnel.
Il test viene ripetuto con entrambi i backend. Sui server devono corrispondere indirizzo client previsto, servizio e percorso di ritorno. Un ping all’IP virtuale non sostituisce un vero test HTTPS, SAP o di un’altra applicazione.
Testare una regola firewall con Log Viewer e Packet Capture aiuta nella verifica combinata di regola, NAT e percorso dei pacchetti.
Delimitare sistematicamente gli errori
Il tunnel è verde, ma l’IP virtuale non risponde
Verificare prima la route SD-WAN su Firewall 2: sorgente, destinazione, servizio e gateway XFRM corrispondono? Controllare poi la Rule ID e la NAT Rule ID su Firewall 1. Se manca la NAT Rule ID, Original source, Original destination, servizio o posizione della regola non corrispondono.
Il DNAT corrisponde, ma il server non risponde
Controllare l’oggetto server list, il servizio locale e il gateway del server. Il percorso di ritorno deve passare da Firewall 1 affinché la sessione NAT esistente traduca nuovamente la risposta su 10.10.10.1. Non aggiungere come scorciatoia una regola MASQ ampia, perché può falsare la diagnosi.
Solo un server riceve connessioni
Usare più sessioni realmente nuove e chiudere le connessioni Keep-alive esistenti. Confrontare poi server list, Load balancing method e NAT Rule ID. Se un backend non funziona direttamente, riparare prima il suo servizio o il percorso locale.
Il traffico prende un’altra route
Controllare posizione e Traffic Count delle route SD-WAN e i gateway XFRM selezionati. Policy Tester non considera completamente le route SD-WAN; usare insieme Log Viewer, Route lookup e Packet Capture.
Eseguire un rollback sicuro
Prima della modifica si documentano backup della configurazione, stato del tunnel, indirizzi XFRM, oggetti gateway, regole e route. Se il nuovo percorso non funziona:
- Disattivare la nuova regola DNAT.
- Disattivare le due nuove route SD-WAN.
- Ripristinare le regole firewall specifiche allo stato precedente.
- Rimuovere gateway XFRM e indirizzi di trasferimento solo se nessun’altra route li utilizza.
- Testare nuovamente il tunnel e il flusso applicativo originali.
Non eliminare un gateway o un’interfaccia XFRM finché Object usage mostra ancora dipendenze. Backup e ripristino di Sophos Firewall spiega il percorso sicuro di backup e recupero.