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 scelte, 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.
- Se si usa SD-WAN, creare su ciascun firewall un gateway verso l’indirizzo XFRM del peer.
- Instradare
VIP-App(198.51.100.10/32) e la rete client verso XFRM con route statiche, dinamiche o SD-WAN secondo l’architettura esistente. - 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. Creare prima un backup della configurazione e documentare lo stato iniziale. 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.
Questa procedura specifica richiede un tunnel route-based con Any come rete locale e remota, interfacce XFRM indirizzate e routing esplicito. Un tunnel route-based con Traffic Selectors può raggiungere lo stesso obiettivo, ma SFOS crea le route dai selettori e i passaggi per il gateway XFRM non si applicano senza modifiche. La procedura non si applica a IPsec policy-based.
Topologia di esempio
Nell’esempio, i client di 192.0.2.0/24 accedono all’indirizzo virtuale 198.51.100.10. I server 10.0.20.21 e 10.0.20.22 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.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
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.
L’esempio conserva gli indirizzi client con Translated source (SNAT): Original. Entrambi i backend devono quindi avere un percorso di ritorno verso 192.0.2.0/24 attraverso il firewall dei server. Se non è possibile, può servire uno SNAT pianificato; nasconde l’indirizzo client e non è una soluzione generale per un routing errato.
192.0.2.0/24 e 198.51.100.0/24 sono reti di documentazione; 10.0.20.0/24 è la rete server dell’esempio.
Conservare lo stato iniziale
Prima di qualsiasi modifica, creare un backup della configurazione e annotare stato IPsec, indirizzi XFRM, ordine di routing e SD-WAN, Rule ID firewall e NAT, contatori esistenti e gateway predefiniti dei backend. Non usare come test le sessioni già stabilite.
Creare gli oggetti IP
Sul firewall dei server aprire Hosts and services > IP host > Add. Creare VIP-App con IP version IPv4, Type IP e l’indirizzo virtuale, quindi Remote-Clients con Type Network. Creare App-Backends con Type IP list e gli indirizzi dei server separati da virgole. In SFOS 22 una IP list contiene fino a 800 indirizzi e non può appartenere a un IP host group. Usare la lista direttamente come Translated destination (DNAT).
I valori concreti degli oggetti dell’esempio sono:
VIP-App: IP versionIPv4, TypeIP, IP address198.51.100.10.Remote-Clients: TypeNetwork, IP address192.0.2.0, Subnet/24.App-Backends: IP versionIPv4, TypeIP list, IP addresses10.0.20.21,10.0.20.22.
Definire le route del tunnel
Le route SD-WAN seguenti servono solo se SD-WAN è già il metodo di routing scelto. Un tunnel Any-to-Any può usare anche route statiche o dinamiche: lato client instradare VIP-App (198.51.100.10/32) verso XFRM, lato server Remote-Clients verso XFRM. Non dedurre né duplicare route senza verificare la route precedence esistente.
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.
Se SD-WAN è già lo standard di routing
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.
La route SD-WAN su Firewall 2 inoltra il traffico da 192.0.2.0/24 a 198.51.100.10 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.
Firewall 1 deve avere una route effettiva verso 192.0.2.0/24 tramite XFRM. Non presumere che una route SD-WAN speculare gestisca le risposte: le route SD-WAN si applicano ai reply packets solo se è attivo set routing sd-wan-policy-route reply-packet enable. Verificare questa impostazione globale o usare il routing statico o dinamico esistente.
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:
- Rule name:
DNAT-VPN-VIP-App - Rule position: sopra le regole NAT più ampie che potrebbero corrispondere
- Original source:
192.0.2.0/24 - Translated source:
Original - Original destination:
198.51.100.10 - Original service: il servizio applicativo reale, ad esempio
HTTPS - Translated destination: oggetto server list con
10.0.20.21e10.0.20.22 - Translated service:
Original - Inbound interface / Outbound interface:
Any(obbligatorio nei campi NAT per il traffico VPN) - Load balancing method:
Round robin - Health check: attivo, Probe method
TCP, Port443
Il DNAT non consente traffico da solo. La regola firewall, la route del tunnel scelta 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.
Round robin invia le nuove richieste in sequenza. Senza Health check, SFOS considera disponibili tutti i membri e può scegliere un server guasto. Impostare Probe interval, Response time-out e Deactivate host after; una probe TCP non sostituisce il controllo applicativo. Il NAT vale solo per il primo pacchetto: una modifica non sposta le sessioni stabilite e richiede nuove connessioni di test.
Creare la regola firewall corrispondente
La regola in uscita usa LAN come Source zone e VPN come Destination zone. La sorgente è 192.0.2.0/24, la destinazione è 198.51.100.10, il servizio corrisponde all’applicazione e il logging resta attivo durante l’introduzione.
La regola firewall in ingresso consente solo il flusso previsto:
- Rule name:
Allow-VPN-VIP-App - Rule position: sopra le regole sovrapposte
- Action:
Accept - Source zone:
VPN - Source networks and devices:
192.0.2.0/24 - Destination zone: zona dei backend tradotti,
LANin questo esempio - Destination networks: solo
198.51.100.10 - Services: solo il servizio applicativo, ad esempio
HTTPS - Log firewall traffic: attivato
SFOS cerca prima il DNAT, quindi usa nella regola firewall la zona della destinazione tradotta. Destination networks resta la VIP originale. Verificare posizione e Rule ID con traffico reale.
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 verificare sorgente, Firewall Rule ID prevista e NAT Rule ID. Confrontare la VIP prima del NAT e il backend tradotto con un Packet Capture ristretto; non dedurre la traduzione da un campo destinazione ambiguo. La cattura mostra anche l’ingresso su XFRM e il ritorno attraverso lo stesso firewall.
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
Nessun NAT Rule ID
Controllare Original source, VIP-App, HTTPS e la posizione della regola NAT. Verificare anche che una regola NAT precedente non corrisponda per prima. Dopo una correzione creare una nuova connessione, perché le sessioni esistenti non vengono rivalutate dal NAT.
Il DNAT corrisponde, ma la regola firewall no
Le Destination zones devono corrispondere alla zona degli indirizzi backend tradotti, non alla VIP né genericamente a VPN. Destination networks rimane VIP-App. Controllare di nuovo la Rule ID e l’evento di scarto in Log Viewer.
Un backend rimane irraggiungibile
Confrontare stato dell’Health Check, metodo di probe e porta con il servizio reale. Senza Health Check, SFOS può selezionare un membro guasto. Anche un probe TCP riuscito non convalida applicazione, TLS o autorizzazione; testare il backend direttamente nella rete server e poi tramite una nuova sessione VIP.
La risposta segue il percorso errato
Controllare il gateway predefinito o la route specifica del backend, la route verso Remote-Clients e Packet Capture sul firewall dei server. Non aggiungere una regola MASQ ampia come scorciatoia diagnostica. Con SD-WAN controllare anche posizione, route precedence, monitoring e Route only through specified gateways.
Eseguire un rollback sicuro
Disattivare prima il DNAT per bloccare nuove sessioni, quindi lasciare terminare o chiudere quelle esistenti nella finestra di manutenzione. Le modifiche NAT non vengono rivalutate per connessioni stabilite. Disattivare poi solo regole e route create per questo percorso e ripristinare l’ordine documentato.
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 solo le route statiche o SD-WAN create per questo percorso.
- Ripristinare le regole firewall specifiche allo stato precedente.
- Rimuovere solo i nuovi gateway e gli indirizzi XFRM appena assegnati quando non esistono dipendenze.
- Testare nuovamente il tunnel e il flusso applicativo originali.
Non eliminare un gateway finché Object usage mostra ancora dipendenze. L’interfaccia XFRM è creata dal tunnel; non eliminare un tunnel esistente che trasporta altre reti. Backup e ripristino di Sophos Firewall spiega il percorso sicuro di backup e recupero.