Linux: controlli rapidi quando il server non prende IP via DHCP

Diagnosi probabile

Quando un server Linux non prende un indirizzo IP via DHCP, le cause più comuni sono poche e quasi sempre verificabili in pochi minuti: il servizio di rete non sta gestendo l’interfaccia corretta, il client DHCP non parte, c’è un errore di configurazione su NetworkManager o systemd-networkd, oppure il server vede il link fisico ma non riceve risposta dal DHCP della rete.

In ambienti VPS o hosting virtualizzati il problema può essere anche esterno alla macchina: MAC address cambiato, porta virtuale non collegata, rete del provider non attiva, VLAN errata o lease DHCP scaduto senza rinnovo. Su server fisici, invece, conviene controllare prima il cavo, lo switch, la porta e il link layer.

La diagnosi giusta parte sempre da un punto semplice: l’interfaccia è up, ma senza IP, oppure l’interfaccia non sale proprio? Da lì si decide se intervenire sulla configurazione locale o se fermarsi a verificare la rete a monte.

Verifiche immediate

1. Controlla lo stato delle interfacce e verifica se il link è presente. Il comando seguente deve mostrarti almeno una scheda con stato UP o LOWER_UP se il cavo o la virtual NIC sono corretti.

   ip link show

2. Verifica se l’interfaccia ha un indirizzo IP assegnato. Se non compare nessun indirizzo in IPv4, il problema è confermato sul lato DHCP o configurazione rete.

   ip addr show

3. Controlla quale gestore di rete è attivo. Su molte distribuzioni moderne sarà NetworkManager oppure systemd-networkd; se nessuno dei due gestisce la scheda, il DHCP non partirà.

   systemctl status NetworkManager --no-pager

   systemctl status systemd-networkd --no-pager

4. Leggi i log di rete recenti per cercare errori DHCP, timeout o conflitti di configurazione. L’esito atteso è un messaggio che indichi il tentativo di lease oppure un errore più preciso da correggere.

   journalctl -b | grep -Ei 'dhcp|network|NetworkManager|systemd-networkd|lease'

5. Se sei in una VPS, verifica dal pannello del provider che la NIC virtuale sia collegata e che non sia cambiato il MAC address atteso. Se hai accesso alla console remota, controlla anche se la macchina vede il link ma non riceve il lease.

Soluzione consigliata passo-passo

1. Identifica prima il gestore di rete in uso, perché il fix cambia in base allo stack. Se il sistema usa NetworkManager, conviene operare con nmcli; se usa systemd-networkd, bisogna controllare i file in /etc/systemd/network/. Su server più datati potresti trovare ancora ifupdown o script legacy.
2. Se usi NetworkManager, verifica che la connessione sia definita e che l’interfaccia sia associata al profilo corretto. Il comando seguente mostra i profili e il loro stato; l’esito atteso è una connessione attiva o comunque disponibile per l’interfaccia giusta.

   nmcli device status

   nmcli connection show

3. Se la connessione esiste ma non ottiene IP, riattivala in modo controllato. Questo è un intervento reversibile e di basso rischio, adatto come primo tentativo.

   nmcli connection down "NOME_CONNessione"

   nmcli connection up "NOME_CONNessione"

   Il controllo successivo deve mostrare un indirizzo IPv4 nella scheda corretta con ip addr show.

4. Se il profilo è errato, imposta DHCP sulla connessione corretta. Prima fai una copia dei file di configurazione se lavori via file e non da CLI. Su sistemi con NetworkManager il profilo può essere gestito da GUI, ma il principio è sempre lo stesso: l’interfaccia deve usare ipv4.method auto e non avere impostazioni statiche in conflitto.
5. Su systemd-networkd, controlla il file di rete relativo all’interfaccia, ad esempio in /etc/systemd/network/10-eth0.network. Prima del cambio fai un backup del file, poi verifica che contenga una sezione [Network] con DHCP=yes. Esempio minimo:

   [Match]
   Name=eth0
   
   [Network]
   DHCP=yes

   Dopo la modifica, riavvia il servizio e verifica il lease con ip addr show e i log di sistema.

6. Se il client DHCP non ottiene risposta, prova a rilasciare e rinnovare il lease. Questo aiuta a capire se il problema è un lease corrotto o un blocco temporaneo della rete.

   dhclient -r eth0

   dhclient -v eth0

   L’esito atteso è la ricezione di un indirizzo, di gateway e dei DNS dal server DHCP. Se il comando fallisce per timeout, il problema è quasi certamente fuori dal client locale.

7. Se l’interfaccia non sale proprio, controlla il nome corretto della scheda e la corrispondenza con la configurazione. Su sistemi moderni il nome può essere ens18, enp1s0 o simili, non necessariamente eth0. Un nome sbagliato nel file di configurazione impedisce il DHCP anche se tutto il resto è corretto.
8. Se sei in ambiente virtuale, verifica che la scheda sia collegata alla rete giusta e che non ci siano restrizioni sul MAC address. Alcuni provider assegnano IP solo a MAC autorizzati; se hai clonato la VM o cambiato interfaccia, il DHCP può rifiutare il lease.
9. Se la macchina deve essere raggiungibile subito e la rete automatica continua a fallire, applica temporaneamente un IP statico solo se conosci indirizzo, gateway e netmask corretti. È una misura di continuità, non la soluzione definitiva. Dopo il ripristino del servizio, torna alla configurazione DHCP per evitare conflitti futuri.

Alternativa B se il problema persiste

1. Riavvia solo il servizio di rete coinvolto, non l’intero server, per limitare l’impatto. Con NetworkManager si usa il riavvio del servizio; con systemd-networkd si ricarica la configurazione. L’esito atteso è il rinnovo della sessione di rete senza perdere altri servizi.
2. Controlla se esiste un firewall o una policy locale che blocca il traffico DHCP, in particolare UDP 67 e 68. In scenari particolari, regole troppo restrittive possono impedire sia la richiesta sia la risposta DHCP.
3. Se il server è in una LAN aziendale, verifica che il DHCP server sia attivo e che il pool non sia esaurito. Un pool senza indirizzi liberi produce un timeout identico a quello di un guasto locale, ma il fix va fatto lato infrastruttura di rete.

Controlli finali / rollback

1. Conferma che l’interfaccia abbia un IPv4 valido, gateway e DNS corretti. Il controllo minimo è questo:

   ip addr show eth0

   ip route

   L’esito atteso è la presenza di una route di default verso il gateway della rete.

2. Verifica la connettività reale e non solo la presenza dell’IP. Il test deve dimostrare che il server raggiunge prima il gateway e poi una destinazione esterna affidabile.

   ping -c 3 <gateway>

   ping -c 3 1.1.1.1

   Se il ping al gateway funziona ma quello verso Internet no, il problema è oltre il DHCP e riguarda routing o firewall.

3. Controlla la risoluzione DNS solo dopo aver confermato la connettività IP. Se il ping a un IP funziona ma i nomi no, il lease DHCP potrebbe aver fornito DNS errati o la configurazione resolver è incompleta.
4. Rollback: se il fix DHCP rompe la connettività, ripristina il file di configurazione salvato prima della modifica oppure riporta il profilo NetworkManager alla versione precedente. Se hai impostato temporaneamente un IP statico, annota la configurazione e rimuovila solo dopo aver ristabilito il DHCP corretto.
5. Prima di chiudere l’intervento, salva l’evidenza utile: output di ip addr, ip route e l’estratto dei log DHCP. Sono i tre dati più utili per capire se il problema è locale, del provider o della rete a monte.

Nota pratica: se il server è una VPS, partire dalla console del provider è spesso più rapido della shell remota, perché ti permette di distinguere subito tra problema di rete reale e semplice perdita di accesso SSH.