Configurare e testare un IP alias su Sophos Firewall
Un IP alias associa un indirizzo IPv4 o IPv6 aggiuntivo a un’interfaccia fisica esistente di Sophos Firewall. È utile quando un provider fornisce più indirizzi pubblici tramite la stessa connessione WAN oppure quando un’interfaccia interna deve servire una seconda subnet durante una migrazione.
La distinzione importante è che un alias non è una seconda connessione Internet, una zona separata o un percorso gateway indipendente. L’indirizzo utilizza la stessa interfaccia fisica principale. Routing, regole firewall, NAT e Device Access devono quindi continuare a corrispondere al design esistente dell’interfaccia.
⚠️ Prima di aggiungere un IP alias pubblico, documentare un backup aggiornato, una connessione amministrativa indipendente, l’assegnazione del provider, lo stato ARP originale e le regole firewall e NAT pianificate. Un indirizzo aggiuntivo non pubblica da solo un server, ma può rendere raggiungibili i servizi locali del firewall in base alle regole Device Access della zona principale.
L’esempio utilizza IPv4 su un’interfaccia WAN. SFOS supporta anche alias IPv6 quando la versione IP corrisponde all’interfaccia principale. Neighbor Discovery IPv6 e NAT66 non fanno tuttavia parte di questo esempio specifico.
IP alias in otto passaggi
- Confermare che il provider o la rete interna fornisca realmente l’indirizzo aggiuntivo tramite la stessa interfaccia fisica.
- Documentare l’interfaccia principale, la versione IP, l’indirizzo, la maschera di subnet e lo scopo.
- Controllare Device Access, le regole esistenti e un percorso di gestione indipendente.
- Associare l’indirizzo all’interfaccia principale in Network > Interfaces > Add interface > Add alias.
- Se necessario per regole e NAT, creare un IP Host con un nome chiaro e con esattamente questo indirizzo.
- Configurare DNAT o SNAT solo per il flusso previsto; gestire separatamente il traffico di sistema.
- Verificare percorso del provider, ARP, Firewall Rule ID, NAT Rule ID e entrambe le direzioni con una nuova connessione.
- Testare appliance sostitutiva, failover HA e rollback in una finestra di manutenzione con lo stesso flusso.
Quando è adatto un IP alias
Un IP alias è adatto quando più indirizzi devono utilizzare lo stesso percorso fisico di livello 2 e lo stesso gateway. Casi tipici:
- più indirizzi IPv4 pubblici su una connessione WAN statica;
- un indirizzo pubblico dedicato per DNAT, WAF o un servizio di posta;
- un indirizzo sorgente fisso per traffico inoltrato selezionato;
- una seconda subnet interna sullo stesso segmento fisico durante una migrazione controllata;
- più indirizzi del provider nella stessa subnet, per i quali interfacce WAN separate causerebbero problemi ARP.
Più interfacce WAN nella stessa subnet non rappresentano una soluzione pulita. Sophos avverte che i gateway possono diventare irraggiungibili a causa di problemi ARP e indica alias o LAG come forme di interfaccia appropriate. Zone e interfacce su Sophos Firewall spiega la scelta di base tra porte fisiche, VLAN, LAG, bridge e XFRM.
Un alias non è adatto se servono una seconda linea, un gateway proprio, uno stato del link indipendente, una zona di sicurezza diversa o un vero failover. In questi casi occorre un design dedicato di interfaccia, VLAN, LAG, WAN o routing.
Se il firewall non deve possedere localmente un indirizzo IPv4 aggiuntivo, ma deve soltanto rispondere per suo conto alla richiesta ARP su un segmento collegato direttamente, si tratta di un design diverso. Configurare Proxy ARP su Sophos Firewall spiega la scelta e la procedura CLI e di test strettamente limitata.
Esempio e valori da sostituire
L’esempio pubblica un servizio HTTPS interno tramite un secondo indirizzo pubblico:
- Interfaccia principale:
Port2 - Zona principale:
WAN - Indirizzo principale:
203.0.113.9/29 - Gateway del provider:
203.0.113.14 - IP alias:
203.0.113.10/29 - Oggetto host dell’alias:
WAN_ALIAS_APP_203.0.113.10 - Server interno:
APP-DMZ_10.20.40.20 - IP del server:
10.20.40.20 - Servizio:
HTTPS - Host di test esterno:
198.51.100.25
203.0.113.0/24 e 198.51.100.0/24 sono riservati alla documentazione. Nella configurazione di produzione devono essere sostituiti con gli indirizzi assegnati dal provider e con un host di test esterno autorizzato.
La maschera /29 è solo un esempio realistico. Non deve essere copiata se il provider fornisce un blocco instradato, un singolo indirizzo /32 o una dimensione di rete diversa. Sono determinanti la documentazione del provider, il modello ARP o di routing e la versione IP utilizzata sull’interfaccia principale.
Aggiungere l’alias all’interfaccia fisica
In Network > Interfaces, l’indirizzo viene associato direttamente all’interfaccia esistente:
- Selezionare Add interface > Add alias.
- In Physical interface, selezionare
Port2o l’interfaccia principale effettiva. - Impostare IP version su
IPv4. - In IPv4/Netmask, inserire
203.0.113.10e la maschera confermata dal provider. - Salvare con Save.
L’indirizzo aggiuntivo appare quindi sull’interfaccia principale. Se sono presenti più di tre alias, SFOS mostra inizialmente solo i primi tre. Scorrere nell’area degli indirizzi visibile per vedere le altre voci.
Un alias non può essere attivato o disattivato in modo indipendente. Se l’interfaccia fisica principale viene disattivata o perde il link, anche i suoi indirizzi alias diventano irraggiungibili. Viceversa, il salvataggio di un alias non crea una nuova voce gateway o una route separata.
La maschera Add alias non dispone di un campo zona separato. Per i servizi locali del firewall resta quindi rilevante la zona dell’interfaccia principale. Prima di aggiungere un IP alias pubblico, controllare in Administration > Device access quali servizi sono raggiungibili da WAN e utilizzare una Local Service ACL Exception restrittiva per fonti di gestione fisse. SSO o MFA non giustificano un accesso WebAdmin ampio.
Utilizzare l’alias nelle regole e nel NAT
L’alias associato e un IP Host hanno funzioni diverse:
- L’alias rende l’indirizzo presente localmente sull’interfaccia fisica.
- L’IP Host rende lo stesso indirizzo chiaramente selezionabile nei campi delle regole e del NAT.
Un oggetto host da solo non associa un indirizzo all’interfaccia. Viceversa, un alias da solo non pubblica un server e non consente traffico inoltrato. Utilizzare correttamente IP Host e servizi spiega in dettaglio i limiti degli oggetti.
Pubblicare un servizio in ingresso con DNAT
Per l’esempio, in Hosts and services > IP host viene creato l’oggetto WAN_ALIAS_APP_203.0.113.10 di tipo IP con l’indirizzo 203.0.113.10. Successivamente vengono create una regola DNAT restrittiva e una regola firewall corrispondente:
- Original source: reti esterne autorizzate o consapevolmente
Any - Original destination:
WAN_ALIAS_APP_203.0.113.10 - Original service:
HTTPS - Translated destination (DNAT):
APP-DMZ_10.20.40.20 - Translated service (PAT):
Original - Inbound interface:
Port2o l’ingresso effettivamente confermato - Translated source (SNAT): normalmente
Original - Log firewall traffic: attivato
La regola firewall consente lo stesso servizio esterno da WAN alla zona del server interno e utilizza come Destination network l’indirizzo alias pubblico di Original destination. Sorgente, servizio e funzioni di protezione vengono limitati il più possibile. La procedura completa con posizione della regola, loopback e hardening è disponibile in Pubblicare un server con DNAT.
Inviare il traffico inoltrato tramite l’IP alias
Se solo uno specifico server interno deve apparire esternamente come 203.0.113.10, viene creata una regola SNAT dedicata esattamente a questo flusso. Translated source (SNAT) utilizza quindi l’IP Host dell’indirizzo alias. Sorgente, destinazione, servizio e interfacce restano quanto più limitati possibile in base al caso d’uso.
La regola NAT non sostituisce una regola firewall. Inoltre, le regole NAT vengono valutate solo per il primo pacchetto di una nuova connessione. Dopo una modifica occorre aprire una nuova connessione; una sessione già esistente non dimostra il nuovo percorso NAT. NAT su Sophos Firewall spiega l’elaborazione di SNAT, DNAT e PAT.
Gestire separatamente il traffico di sistema del firewall
Il traffico DNS, di autenticazione, di posta o altro traffico generato dal firewall stesso non segue automaticamente una regola SNAT per client inoltrati. Sophos documenta esplicitamente che le configurazioni di routing utilizzano l’interfaccia principale. Se un flusso specifico e giustificato di traffico di sistema deve usare l’IP alias come sorgente, è necessaria una configurazione CLI separata.
Prima della modifica, salvare lo stato iniziale nella Device Console:
show advanced-firewall
L’esempio seguente traduce solo il traffico di sistema tramite Port2 verso la singola destinazione 198.51.100.25, utilizzando l’IP alias 203.0.113.10:
set advanced-firewall sys-traffic-nat add destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10
⚠️ Questo comando modifica l’indirizzo sorgente del traffico del firewall. Non crea una route e non è un sostituto generale di una regola NAT. Destinazione, maschera
/32, interfaccia e IP alias devono corrispondere all’applicazione reale. Dopo la modifica, testare esattamente il servizio interessato e controllare nuovamente la voce conshow advanced-firewall.
Per il rollback, eliminare esattamente la stessa voce con delete:
set advanced-firewall sys-traffic-nat delete destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10
Maschere più ampie traducono il traffico verso un’intera rete di destinazione. Devono essere utilizzate solo se questo ambito più ampio è intenzionale, documentato e testato.
Pianificare alias di subnet diverse
Sophos consente più indirizzi alias di subnet diverse sulla stessa interfaccia fisica, ma stabilisce due condizioni:
- Sophos Firewall deve essere il default gateway degli host interni.
- I dispositivi upstream che fungono da gateway per il traffico del firewall devono disporre di un indirizzo appropriato in ogni subnet alias utilizzata.
Un alias non rende quindi automaticamente operativa una seconda subnet end-to-end. Anche gateway degli host, peer, route di ritorno, ARP o Neighbor Discovery, regole firewall e NAT devono essere corretti per quella subnet.
Per una segmentazione permanente, una VLAN o un’interfaccia fisica dedicata è generalmente più comprensibile. Un alias multi-subnet è più adatto a una transizione pianificata consapevolmente o a un’architettura del provider in cui entrambe le reti condividono realmente lo stesso percorso di livello 2.
DHCP Server e DHCP Relay non possono essere configurati su un Interface Alias. Inoltre, un alias non è un Dedicated HA link valido. Questi requisiti devono utilizzare un’interfaccia fisica o virtuale supportata.
Verificare il percorso dati e ARP
La verifica deve seguire il compito reale e non limitarsi a un ping:
- In Network > Interfaces, controllare interfaccia principale, indirizzo alias, maschera e stato del link.
- Sul dispositivo del provider o upstream, verificare che l’IP alias sia raggiungibile tramite l’indirizzo MAC o il neighbor previsto.
- Da
198.51.100.25, aprire una nuova connessione HTTPS all’IP alias. - In Log Viewer, controllare Firewall Rule ID, NAT Rule ID, Source, Original destination e destinazione tradotta previsti.
- Nel Packet Capture integrato, confrontare l’ingresso su
Port2con l’uscita verso il server. - Sul server interno, confermare che la connessione arrivi e che la risposta ritorni tramite Sophos Firewall.
- Eseguire un test negativo con una porta volutamente non consentita e una sorgente non autorizzata.
- In HA, ripetere un failover controllato con una nuova connessione senza presumere che una sessione esistente continui senza interruzioni.
Un ping all’IP alias è significativo solo se Ping è consapevolmente consentito per la zona principale in Device Access. Per un servizio HTTPS pubblicato, il test TCP e applicativo reale è una prova di successo migliore. Packet Capture su Sophos Firewall spiega filtri, confronto tra interfacce ed esportazione.
Circoscrivere gli errori in modo sistematico
L’alias è visibile ma non raggiungibile dall’esterno
- Confermare che il provider fornisca realmente l’indirizzo specifico tramite
Port2. - Confrontare IP, maschera e interfaccia principale con l’assegnazione del provider.
- Controllare la voce ARP o neighbor sul dispositivo upstream.
- Esaminare Device Access solo per gli accessi al firewall stesso.
- Per i servizi inoltrati, controllare Firewall Rule ID, NAT Rule ID e percorso di ritorno del server.
Dopo la sostituzione di un firewall, il router upstream può conservare ancora il vecchio indirizzo MAC per l’IP alias. In questo caso Sophos indica di svuotare la cache del router o di riavviarlo. In pratica, aggiornare prima solo la voce ARP o neighbor interessata con la procedura documentata del dispositivo upstream; un riavvio completo deve avvenire in una finestra di manutenzione.
Il traffico in uscita continua a utilizzare l’indirizzo principale
Per il traffico inoltrato, controllare se la regola SNAT prevista corrisponde a una nuova connessione. Source, Destination, Service, Inbound interface, Outbound interface e NAT Rule ID devono coincidere.
Per il traffico di sistema del firewall, una normale regola SNAT non rappresenta la prova corretta. Controllare invece la voce sys-traffic-nat specifica, la route, la destinazione e il flusso di pacchetti effettivo. Non aggiungere una traduzione ampia sulla base di un sospetto.
Solo la seconda subnet interna non funziona
Verificare che Sophos Firewall sia realmente il default gateway degli host interessati e che il dispositivo upstream disponga di un indirizzo appropriato in questa subnet. Controllare poi separatamente route di ritorno, maschera dell’host, ARP, regola firewall e NAT. Un alias visibile non dimostra queste dipendenze.
Il tunnel IPsec tramite un alias è attivo ma non trasporta traffico
Registrare prima versione e build SFOS, modello dell’appliance, utilizzo di PPPoE, associazione dell’alias, IPsec Acceleration e percorso effettivo dei pacchetti. SFOS 22 presenta casi limite di alias e accelerazione legati a versioni specifiche che non devono essere applicati a ogni problema con alias. La procedura di diagnosi delimitata è disponibile in Troubleshooting IPsec per interfacce alias.
Operatività, appliance sostitutiva e rollback
Gli indirizzi alias devono essere documentati insieme ad assegnazione del provider, DNS, certificati, NAT, regole firewall e servizio responsabile. Prima di sostituire un firewall, gli alias pubblici e il previsto cambio ARP o neighbor devono far parte della verifica.
Per un rollback:
- Documentare gli utilizzi attivi dell’alias e dell’IP Host associato.
- Rimuovere in modo controllato i servizi pubblicati da DNS, monitoraggio o load balancing.
- Disattivare prima le regole firewall e NAT associate e confermare l’interruzione del flusso previsto.
- Eliminare ogni voce
sys-traffic-natcon l’esatto comandodelete. - Eliminare alias e oggetto host solo quando non rimane alcuna dipendenza produttiva.
- Controllare nuovamente interfaccia principale, indirizzo principale, gateway e servizi non interessati.
- In HA, ripetere la stessa verifica dopo un failover pianificato.
Un alias non può essere utilizzato come Dedicated HA link. HA su Sophos Firewall spiega interfacce, indirizzi di amministrazione del peer e test di failover necessari per un cluster.
Checklist
- Assegnazione del provider, interfaccia principale, versione IP, indirizzo e maschera sono confermati.
- Sono disponibili un backup e una connessione amministrativa indipendente.
- Device Access e Local Service ACL della zona principale sono stati controllati.
- Alias e IP Host con lo stesso nome non vengono confusi.
- Le regole firewall e NAT sono limitate al flusso previsto.
- Il traffico di sistema viene tradotto separatamente solo in presenza di un’esigenza giustificata.
- Firewall Rule ID, NAT Rule ID, ARP e entrambe le direzioni sono confermati.
- Una sorgente non autorizzata e un servizio non consentito sono stati testati negativamente.
- Appliance sostitutiva, failover HA e rollback sono documentati.