Configurare Sophos Firewall come server DHCP

Sophos Firewall può distribuire direttamente ai client indirizzi IPv4, gateway, server DNS e altre impostazioni di rete. A tale scopo si crea un server per l’interfaccia client in Network > DHCP, si definisce l’intervallo di indirizzi e si verifica quindi che il client riceva un lease corretto.

Procedura rapida: aprire Network > DHCP > Server > Add, selezionare l’interfaccia e l’intervallo di indirizzi, attivare Use interface IP as gateway, configurare con attenzione i DNS e salvare. Verificare quindi il servizio DHCP server in System services > Services e controllare l’indirizzo assegnato in IPv4 lease.

Questa guida tratta un server DHCPv4 per client nella rete direttamente collegata. Se un server DHCP centrale deve servire un’altra sottorete, consultare Configurare e testare DHCP Relay su Sophos Firewall. PXE, VoIP e valori specifici del produttore sono descritti in Configurare le opzioni DHCP su Sophos Firewall.

Con IPv6, l’assegnazione degli indirizzi e il gateway hanno ruoli diversi. La procedura completa è descritta in Configurare e testare un server DHCPv6 su Sophos Firewall.

Esempio e pianificazione degli indirizzi

L’esempio utilizza una VLAN client con i valori seguenti:

Interfaccia: VLAN20 - 10.20.0.1/24
Intervallo dinamico: da 10.20.0.100 a 10.20.0.199
Gateway: 10.20.0.1
Mapping statico per una stampante: 10.20.0.20
Server DNS interni: 10.10.0.10 e 10.10.0.11
Domain Name: corp.example

L’intervallo dinamico si trova nella rete dell’interfaccia, ma non include né l’indirizzo di rete, né l’indirizzo di broadcast, né il gateway. Nell’esempio, gli indirizzi inferiori a 10.20.0.100 rimangono riservati all’infrastruttura e ai mapping statici. Questo impedisce all’intervallo DHCP di assegnare dinamicamente anche gli indirizzi riservati. La separazione non protegge però da un altro dispositivo sul quale sia stato configurato manualmente lo stesso indirizzo IP.

Prima dell’attivazione occorre verificare quali indirizzi sono già utilizzati da switch, access point, stampanti o server. Se nella stessa VLAN è ancora attivo un altro server DHCP, bisogna prima stabilire quale server sarà responsabile in futuro. Due server non coordinati possono distribuire gateway o server DNS differenti e causare problemi intermittenti.

L’interfaccia deve già disporre dell’indirizzo IP statico corretto. L’interazione tra interfaccia, zona e VLAN è descritta in Configurare un’interfaccia VLAN su Sophos Firewall.

Configurare il server DHCP

Aprire Network > DHCP.
In Server, fare clic su Add.
Inserire un nome univoco, ad esempio dhcp-vlan20-clients.
In Interface, selezionare l’interfaccia client VLAN20 - 10.20.0.1.
In Dynamic IP lease, aggiungere l’intervallo da 10.20.0.100 a 10.20.0.199.
Inserire 255.255.255.0 come Subnet mask per la rete /24 dell’esempio.
Attivare Use interface IP as gateway. I client ricevono così 10.20.0.1 come Gateway.
Definire server DNS, Domain name e durate dei lease in base alla rete.
Se necessario, aggiungere mapping statici MAC-IP.
Salvare con Save.

Per i client connessi direttamente, l’interfaccia selezionata determina la rete sulla quale il firewall risponde alle richieste DHCP. L’intervallo dinamico deve quindi appartenere alla sottorete di questa interfaccia. I server DHCP possono essere configurati su interfacce fisiche e su interfacce VLAN, Wireless e Bridge, ma non su un Interface Alias. Non è possibile configurare contemporaneamente un server DHCPv4 su un’interfaccia già utilizzata come DHCP Relay.

Per i client connessi direttamente, lasciare disattivato Accept client request via relay. L’opzione serve solo se questa configurazione del server deve accettare tramite un relay agent le richieste provenienti da una sottorete client remota. Ogni rete client remota richiede una configurazione server adeguata con il proprio gateway; il progetto completo è descritto nella guida DHCP Relay.

Queste configurazioni server possono condividere la stessa interfaccia DHCP sulla quale il server riceve le richieste inoltrate. Occorre distinguere l’interfaccia di ascolto dalla sottorete client remota: l’intervallo di indirizzi, la maschera di sottorete e il gateway di ogni configurazione appartengono alla rispettiva rete client. Il server assegna indirizzi della sottorete dell’indirizzo sorgente del relay agent; condividere un’interfaccia di ascolto non sostituisce quindi una configurazione separata per ogni rete client.

Scegliere correttamente gateway e DNS

In una normale rete client, il gateway è l’indirizzo IP di Sophos Firewall su questa interfaccia. Nell’esempio, i client ricevono quindi 10.20.0.1.

Con Use device’s DNS settings, il firewall distribuisce ai client i propri server DNS configurati. Questa scelta è adatta se tali server possono risolvere sia i nomi pubblici sia quelli interni necessari. In un ambiente AD, di norma si inseriscono i server DNS interni affinché Domain Controller, servizi interni e domini di ricerca funzionino in modo affidabile. I soli resolver pubblici in genere non sono sufficienti.

Domain name assegna un suffisso DNS alla scheda di rete. Con corp.example, ad esempio, il client può completare l’hostname fileserver in fileserver.corp.example. Questo non sostituisce né un record DNS né un server DNS raggiungibile; entrambi vanno verificati separatamente.

Se i client ricevono come server DNS l’indirizzo IP del firewall, Sophos Firewall può inoltrare le richieste per determinate zone interne ai server competenti. Questo caso è descritto in Configurare le DNS Request Routes su Sophos Firewall. Se invece il DHCP distribuisce direttamente gli indirizzi di altri server DNS, le richieste dei client non raggiungono le Request Routes del firewall.

I campi WINS server 1 e WINS server 2 sono destinati esclusivamente agli ambienti NetBIOS meno recenti. Devono rimanere vuoti se nessun client o applicazione richiede ancora un servizio WINS. Se WINS è tuttora in uso, occorre inserire gli indirizzi reali dei server e verificare la risoluzione dei nomi con un client interessato.

Impostare durate dei lease adeguate

Default lease time è la normale durata del lease assegnata al client. Max lease time è il limite massimo; alla sua scadenza, il client deve inviare una nuova richiesta al server DHCP. Entrambi i valori sono espressi in minuti.

Nelle reti aziendali o di dispositivi stabili sono utili lease più lunghi, perché la composizione cambia raramente. Nelle reti guest, di formazione o WLAN con un ricambio elevato, un lease più breve impedisce ai dispositivi non più connessi di occupare a lungo l’intervallo.

Lease molto brevi generano invece un numero inutilmente elevato di rinnovi. Non esiste quindi un valore ideale universale: sono determinanti la dimensione dell’intervallo e la frequenza con cui cambiano i client.

Conflict detection controlla un indirizzo prima dell’assegnazione e aiuta a individuare indirizzi IP già in uso. La funzione è particolarmente utile quando sono ancora presenti dispositivi configurati manualmente o un precedente piano di indirizzamento non completamente documentato.

Creare un mapping statico IP-MAC

Un mapping statico garantisce che un determinato dispositivo riceva sempre lo stesso indirizzo tramite DHCP. È utile per stampanti, access point o altri dispositivi che devono rimanere raggiungibili, ma continuare a ricevere centralmente valori come gateway e DNS.

In Static IP MAC mapping si inseriscono hostname, indirizzo MAC e indirizzo IP desiderato. Nell’esempio, la stampante con il suo indirizzo MAC effettivo riceve sempre 10.20.0.20. Questo indirizzo si trova intenzionalmente al di fuori dell’intervallo dinamico.

Un mapping DHCP non equivale a un indirizzo IP configurato manualmente sul dispositivo: il dispositivo rimane un client DHCP, mentre il firewall riserva il lease corrispondente. Se un notebook o uno smartphone utilizza un indirizzo MAC WLAN privato o casuale, il mapping deve corrispondere all’indirizzo MAC effettivamente utilizzato dal dispositivo in quella WLAN.

Un singolo indirizzo MAC può ricevere al massimo cinque indirizzi IP statici, purché appartengano a sottoreti diverse. Un mapping normale in una sola rete non richiede l’impostazione globale.

In SFOS 23, quando lo stesso indirizzo MAC è associato in più configurazioni di server DHCP, impostare Lease scope for static binding su Global in Network > DHCP > Advanced server settings. I client possono quindi ottenere un indirizzo da qualsiasi server DHCP configurato sul firewall, indipendentemente da dove sia configurata l’associazione IP-MAC statica. Network limita l’assegnazione al server che contiene l’associazione. Annotare prima il valore precedente, quindi testare ogni scope interessato con un nuovo lease client. Per il ripristino, reimpostare esattamente il valore annotato.

SFOS 22: associazione globale tramite Device Console

Prima di modificare l’assegnazione globale, effettuare l’accesso SSH e leggere il metodo e l’ambito DHCP attuali nella Device Console:

system dhcp conf-generation-method show
system dhcp static-entry-scope show

Modificare quindi solo i valori che differiscono dallo stato richiesto:

system dhcp conf-generation-method new
system dhcp static-entry-scope global

L’impostazione riguarda tutte le configurazioni dei server DHCP. Non è necessaria per normali mapping singoli e deve quindi essere modificata solo per questo caso con più ambiti DHCP.

I valori predefiniti documentati sono old e network. Quando gli indirizzi MAC sono associati più volte, il vecchio metodo può fornire informazioni errate, ad esempio server DNS o gateway. Non sovrascrivere uno stato già personalizzato. Il ripristino utilizza esattamente i valori letti in precedenza; solo per uno stato predefinito confermato sono system dhcp static-entry-scope network e system dhcp conf-generation-method old. In seguito, testare ogni ambito DHCP interessato con un nuovo lease client.

Verificare il servizio e testare il lease

Dopo il salvataggio, verificare in System services > Services che DHCP server sia in esecuzione. Se il servizio è arrestato, avviarlo da questa sezione.

⚠️ In un cluster HA, Sophos supporta il servizio DHCP in modalità Active-passive, ma non in modalità Active-active. Verificare questo limite prima della messa in servizio; cambiare modalità HA non è una procedura di troubleshooting per un singolo ambito DHCP.

Collegare quindi un client di test controllato alla VLAN corretta. In Windows è possibile richiedere e verificare un nuovo lease nel modo seguente:

ipconfig /release
ipconfig /renew
ipconfig /all

⚠️ ipconfig /release interrompe la connessione IPv4 corrente. Non eseguire il comando tramite quella stessa connessione remota se non è disponibile un accesso alternativo.

Il client deve ricevere un indirizzo compreso tra 10.20.0.100 e 10.20.0.199, il gateway 10.20.0.1 e i server DNS previsti. In Network > DHCP > IPv4 lease, il firewall mostra l’indirizzo assegnato con data e ora di inizio e fine, indirizzo MAC e hostname.

Per verificare il funzionamento devono risultare corretti almeno questi punti:

Il client riceve un indirizzo dall’intervallo corretto.
Gateway e server DNS corrispondono alla pianificazione.
Il gateway è raggiungibile.
I nomi interni ed esterni vengono risolti.
Il client raggiunge solo le reti e i servizi consentiti dalla relativa regola firewall.

Il client non riceve alcun indirizzo o ne riceve uno errato

Se il client non riceve un lease, controllare prima l’interfaccia, la VLAN e lo stato del servizio. Questi sono poi gli errori più frequenti:

Interfaccia errata: il server DHCP non è associato all’interfaccia della rete client.
La VLAN non raggiunge il firewall: l’uplink dello switch non consente la VLAN tagged oppure la porta client è assegnata in modo errato.
Intervallo di indirizzi errato: l’indirizzo iniziale o finale non appartiene alla sottorete dell’interfaccia.
Intervallo esaurito: confrontare il numero e la durata dei lease occupati con la dimensione dell’intervallo configurato. L’elenco dei lease mostra gli indirizzi assegnati, ma non contiene un elenco separato degli indirizzi liberi.
Risponde un altro server DHCP: il client riceve un indirizzo, ma un gateway o server DNS errato.
Policy rule denied per la sorgente 0.0.0.0: se sull’interfaccia non è configurato né un server DHCP né un relay, una richiesta del client può essere scartata con questa voce. Il messaggio non dimostra quindi che la causa sia una normale regola firewall. Verificare prima il server DHCP, il relay e l’assegnazione dell’interfaccia.
È necessario DHCP Relay: il client non si trova nella rete direttamente collegata al server.
Il mapping statico non viene applicato: l’indirizzo MAC inserito non corrisponde a quello effettivamente utilizzato dal client.

Con un’acquisizione dei pacchetti filtrata su port 67 or port 68 si può verificare se vengono scambiati Discover, Offer, Request e ACK e quale server risponde. L’utilizzo dello strumento è descritto in Utilizzare Packet Capture nel WebAdmin di Sophos Firewall.

Se un Discover raggiunge il firewall ma non segue alcun Offer, controllare anche lo stato di dhcpd e il log dhcpd.log. I comandi e i percorsi dei log corrispondenti sono riportati in Controllare servizi e log di Sophos Firewall tramite CLI.

Se il client riceve un indirizzo IP corretto ma non riesce a risolvere i nomi, controllare prima gli indirizzi DNS distribuiti tramite DHCP. Se sono errati o assenti, il problema è ancora nella configurazione DHCP. Se sono corretti, verificare la risoluzione interna dei nomi e l’accesso di rete al server DNS.

Per un’interfaccia RED esiste un ulteriore caso particolare: se il suo indirizzo viene sostituito con un indirizzo esterno all’intervallo dinamico esistente, SFOS disattiva il server DHCP RED associato. Occorre quindi adattare Dynamic IP lease, i mapping statici e i valori DNS alla sottorete risultante dell’interfaccia, oppure creare una nuova configurazione server. Solo dopo si rimette in servizio l’ambito DHCP e lo si verifica con un client.

Sostituire un server DHCP esistente

Durante una migrazione non si deve semplicemente attivare in aggiunta il nuovo server DHCP. I client attivi mantengono il lease precedente; il nuovo server non conosce queste assegnazioni e potrebbe offrire nuovamente un indirizzo ancora in uso.

Per effettuare una sostituzione controllata, procedere come segue:

Documentare l’intervallo, le opzioni, i mapping statici e i lease attivi del server esistente.
Ridurre per tempo la durata del lease sul vecchio server e attendere che i client attivi abbiano rinnovato il lease con il valore più breve.
Arrestare il server esistente e attivare inizialmente il nuovo server con un intervallo transitorio non sovrapposto.
Rinnovare il lease su più client diversi e verificare gateway, DNS e raggiungibilità.
Dopo la scadenza dei vecchi lease, attivare l’intervallo definitivo e ripristinare la normale durata del lease.

Conflict detection è utile durante una migrazione, ma non sostituisce questa pianificazione. La funzione controlla un indirizzo prima dell’assegnazione, ma non mantiene un database dei lease condiviso con il vecchio server.

Per il ripristino, conservare una registrazione completa della configurazione precedente. Se il nuovo scope distribuisce valori errati, disattivare o rimuovere solo questa nuova configurazione server e riattivare in modo controllato il server precedente. System services > Services > DHCP server > Stop, invece, arresta il servizio DHCP globale e quindi tutti gli scope locali; va usato solo se si desidera esattamente questo effetto complessivo. Successivamente rinnovare i lease su più client di prova.

Valori speciali come server di avvio PXE, controller VoIP o opzioni specifiche del produttore devono essere confrontati separatamente prima della sostituzione. Non fanno automaticamente parte della normale distribuzione di indirizzo, gateway e DNS.

Modificare le impostazioni DHCP globali solo se necessario

In SFOS 23, Network > DHCP > Advanced server settings contiene questi due campi dell’interfaccia:

Allow only one lease per client limita ogni client a un solo lease DHCP. Quando l’opzione è attivata, ogni client riceve un solo indirizzo IP in lease.
Negative acknowledgement attiva le risposte DHCPNAK quando un client richiede un indirizzo esterno alla sottorete configurata del server o un indirizzo già assegnato. Conflict detection è invece la verifica separata di un indirizzo prima dell’assegnazione.

Prima di una modifica nell’interfaccia, annotare il valore precedente. Successivamente, rinnovare un lease client, controllare IPv4 lease e, se necessario, una cattura di pacchetti UDP 67/68. Per il ripristino, reimpostare esattamente il valore annotato. Restano valide le indicazioni CLI seguenti sull’impatto globale, sull’identità del client e sui rischi dei NAK.

Altri due interruttori della Device Console si applicano all’intero servizio DHCP. Prima leggere il loro stato:

system dhcp one-lease-per-client show
system dhcp send-dhcp-nak show

one-lease-per-client è disattivato per impostazione predefinita. La guida attuale non spiega come la funzione identifichi il client in tutti i casi particolari. L’attivazione è globale; limitare quindi inizialmente solo il test a un client controllato, quindi verificare la tabella dei lease, il rinnovo e i dispositivi con più interfacce o indirizzi MAC variabili.

send-dhcp-nak è attivato per impostazione predefinita. Un DHCPNAK rifiuta un indirizzo non accettato dal server e riporta il client nella negoziazione DHCP. Disattivarlo può prolungare uno stato client non valido e non è una correzione generale per lease non riusciti.

Gli interruttori si modificano così:

system dhcp one-lease-per-client [enable|disable]
system dhcp send-dhcp-nak [enable|disable]

Le parentesi quadre sono segnaposto; eseguire solo il valore necessario. Dopo una modifica, controllare di nuovo il valore con show, rinnovare un lease, verificare IPv4 lease e, se necessario, acquisire il traffico UDP 67/68. Se erano stati confermati i valori predefiniti, il ripristino usa system dhcp one-lease-per-client disable oppure system dhcp send-dhcp-nak enable. Se lo stato iniziale era personalizzato, ripristinare esattamente i valori rilevati con show prima della modifica e verificare nuovamente entrambe le impostazioni.