Come assegnare più indirizzi IP a una sola interfaccia su Ubuntu

Su Ubuntu, assegnare più indirizzi IP alla stessa interfaccia non è un caso speciale: è un uso normale dello stack di rete, sia che tu stia lavorando con Netplan, con il vecchio ifupdown o con un setup temporaneo via iproute2. Il punto vero non è “come aggiungere un secondo IP”, ma come farlo in modo persistente, verificabile e reversibile, senza rompere routing, default gateway o servizi che ascoltano su un solo indirizzo.

La regola pratica è semplice: se l’IP deve vivere oltre il reboot, usa la configurazione persistente del sistema; se serve solo per un test o per una migrazione, usa il comando runtime e documenta il rollback. In ambienti Ubuntu recenti, la strada standard è Netplan, che poi applica la config a systemd-networkd o a NetworkManager a seconda del backend scelto.

Quando ha senso avere più IP sulla stessa interfaccia

Ci sono casi molto concreti in cui questa configurazione è utile: hosting multi-sito su un singolo server, separazione di servizi legacy che devono bindare su IP diversi, migrazioni graduali, test di compatibilità con ACL esterne, oppure servizi che richiedono indirizzi distinti per motivi contrattuali o di instradamento. Non è una soluzione di architettura “elegante” in assoluto, ma è spesso la più economica e meno invasiva quando hai un solo NIC fisico o un’unica vNIC dietro hypervisor o cloud.

La domanda che devi farti prima di toccare la config non è solo “posso aggiungere un secondo IP?”, ma anche: quel secondo IP deve rispondere sulla stessa subnet? Deve avere lo stesso gateway? Deve essere IPv4 o IPv6? E soprattutto: il provider o il router a monte accettano davvero quell’indirizzo sulla stessa MAC?

Come funziona davvero sul kernel Linux

Linux non pensa in termini di “un IP per interfaccia”. L’interfaccia può avere più indirizzi, ciascuno con una propria entry nella tabella degli indirizzi. Il kernel decide quale usare in uscita in base a routing, policy, scope e preferenze di source address selection. Questo significa che aggiungere un secondo IP non basta: se il routing o i servizi non sono coerenti, puoi ritrovarti con traffico in ingresso corretto ma risposte che partono dall’indirizzo sbagliato.

Per questo motivo, quando configuri più IP, devi controllare almeno tre cose: l’assegnazione degli indirizzi, la presenza o meno di un solo default gateway, e il comportamento dei servizi che espongono porte TCP/UDP. Un web server in ascolto su 0.0.0.0:80 accetta tutte le IP della macchina; uno legato a un IP specifico no.

Verifica rapida dello stato attuale

Prima di cambiare qualcosa, guarda come è messa l’interfaccia adesso. Questo ti dà il punto di partenza e il rollback mentale.

Esegui:

ip addr show dev eth0
ip route show
resolvectl status 2>/dev/null || true

Sostituisci eth0 con il nome reale, ad esempio ens18, enp0s3 o simili. Devi vedere l’IP primario, eventuali IP secondari e la route di default. Se l’output mostra già un secondo IP, ma non è persistente dopo reboot, il problema è di configurazione, non del kernel.

Metodo temporaneo: aggiungere un secondo IP con iproute2

Se devi fare una prova veloce, questo è il modo più diretto. È reversibile e non tocca file di configurazione. Il blast radius è limitato alla sessione corrente, ma attenzione: se stai lavorando da remoto sullo stesso host, un errore di routing può tagliarti fuori comunque.

Aggiungi il secondo indirizzo così:

sudo ip addr add 192.0.2.20/24 dev eth0

Verifica subito:

ip addr show dev eth0

Devi vedere sia l’indirizzo primario sia 192.0.2.20/24. Se l’IP non appare, c’è un errore di sintassi o l’interfaccia non è quella giusta. Se appare ma non risponde da fuori, il problema è a monte: subnet, gateway, ARP, firewall o provider.

Per rimuoverlo:

sudo ip addr del 192.0.2.20/24 dev eth0

Questa è la prima forma di rollback da usare quando vuoi testare senza lasciare tracce permanenti.

Metodo persistente con Netplan

Su Ubuntu moderno, Netplan è la scelta più pulita. Il file tipico sta in /etc/netplan/, per esempio /etc/netplan/01-netcfg.yaml o simili. Prima di modificare, fai una copia del file attuale.

Backup minimo:

sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak

Un esempio di configurazione con due IPv4 sulla stessa interfaccia:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
      addresses:
        - 192.0.2.10/24
        - 192.0.2.20/24
      gateway4: 192.0.2.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

Qui il punto importante è che i due indirizzi stanno nello stesso blocco addresses. Non serve duplicare l’interfaccia. Se la subnet è la stessa, il kernel gestisce entrambi come indirizzi locali associati alla stessa NIC.

Applica la config in modo prudente:

sudo netplan try

netplan try è preferibile a netplan apply quando sei in remoto, perché ti dà una finestra di conferma e rollback automatico se perdi connettività. Se tutto resta stabile, conferma. Se qualcosa va storto, il sistema torna alla configurazione precedente.

Se la prova è già passata, applica in modo definitivo:

sudo netplan apply

Attenzione al gateway: un solo default route, salvo casi specifici

L’errore più comune è pensare che a due IP debbano corrispondere due gateway. Nella maggior parte dei casi no. Se gli IP stanno nella stessa subnet e usano lo stesso upstream, devi mantenere un solo default gateway. Due default route mal pensate generano comportamenti intermittenti, soprattutto su connessioni in uscita e risposte a servizi esposti.

Verifica la tabella di routing con:

ip route show

Devi vedere una route di default coerente. Se hai bisogno di policy routing perché ciascun IP deve uscire da un gateway diverso, allora non stai più facendo una semplice multi-assegnazione: stai entrando nel territorio di source-based routing, e lì serve progettare bene tabelle e regole.

Servizi che ascoltano su un IP preciso

Molti problemi vengono fuori non dalla rete, ma dall’applicazione. Se Nginx, Apache, Postfix, un demone custom o un listener Java è configurato per bindare su un solo indirizzo, il secondo IP non verrà usato anche se è presente correttamente sulla NIC. In quel caso devi controllare il file di servizio o la configurazione dell’app.

Esempi tipici:

Se vuoi che un servizio risponda su entrambi gli IP, spesso la soluzione più semplice è bindare su tutte le interfacce. Ma non farlo a caso: aumenta la superficie esposta. Se il servizio deve restare su un solo IP per policy, esplicitalo e documenta il motivo.

Controlli di reachability e ARP

Se l’IP è configurato ma non risponde, la verifica successiva è capire se il problema è locale o di rete a monte. Dal server, controlla che l’host annunci correttamente il nuovo indirizzo. Su IPv4, un test utile è guardare la tabella ARP e fare un ping mirato verso il gateway.

ip neigh show dev eth0
ping -c 3 192.0.2.1

Se l’ARP non si completa o il ping al gateway fallisce solo per il secondo IP, può esserci un vincolo del provider, un anti-spoofing sul virtual switch, oppure una subnet non autorizzata. In ambienti cloud è frequente: l’indirizzo esiste nel sistema operativo, ma il fabric lo filtra finché non lo registri nel pannello o non lo associ correttamente alla NIC virtuale.

Quando il provider impone IP aggiuntivi “secondary”

Su alcuni VPS, dedicati o ambienti colocation, l’IP secondario non è libero: va dichiarato nel pannello del provider, talvolta con una MAC virtuale o con una subnet dedicata. In quel caso la configurazione Ubuntu da sola non basta. Il sintomo tipico è che tutto sembra corretto localmente, ma dall’esterno non arriva traffico oppure il gateway risponde in modo incoerente.

Qui il controllo da fare non è un comando Linux, ma il pannello del provider: sezione IP addizionali, NIC, subnet, failover IP, MAC virtuale o alias. Se il provider richiede un binding specifico, la configurazione OS va allineata con quella informazione. Senza quel passaggio, stai solo assegnando un indirizzo che la rete upstream non inoltra.

Soluzione con ifupdown su sistemi legacy

Se il sistema non usa Netplan ma il vecchio stack con /etc/network/interfaces, la logica è la stessa: un’interfaccia, più indirizzi. La sintassi però cambia.

auto eth0
iface eth0 inet static
    address 192.0.2.10
    netmask 255.255.255.0
    gateway 192.0.2.1
    up ip addr add 192.0.2.20/24 dev eth0
    down ip addr del 192.0.2.20/24 dev eth0

Questa soluzione funziona, ma oggi è più sensato passare a Netplan se sei su Ubuntu supportato. Se mantieni il legacy, documenta bene il motivo: spesso è per compatibilità con automazioni esistenti o per evitare di toccare ambienti vecchi già stabilizzati.

IPv6: stesso concetto, qualche trappola in più

Con IPv6 è identico: la NIC può avere più indirizzi globali, più address temporanei e link-local. Il problema è che il comportamento di source address selection è più visibile, perché le applicazioni possono uscire con un indirizzo diverso da quello che ti aspetti. Se aggiungi un secondo IPv6, controlla anche se il router annuncia correttamente la prefix delegation e se il firewall consente il traffico in ingresso.

ip -6 addr show dev eth0
ip -6 route show

Se vuoi un IPv6 statico persistente con Netplan, aggiungi il blocco addresses con il prefisso corretto e verifica che non ci siano conflitti con SLAAC o DHCPv6. Mescolare tutto senza criterio produce indirizzi duplicati o preferenze di routing che poi sembrano “casuali”.

Checklist operativa prima di mettere in produzione

Se devi fare questo lavoro su un server esposto, conviene seguire una sequenza fissa e non improvvisare. La parte delicata non è l’aggiunta dell’IP, ma evitare di perdere accesso remoto o creare ambiguità di routing.

Diagnosi dei casi che sembrano uguali ma non lo sono

Ci sono tre scenari che spesso vengono confusi. Primo: l’IP è configurato ma il servizio non risponde. Qui il problema è quasi sempre il bind dell’app o il firewall locale. Secondo: il servizio risponde in locale ma non dall’esterno. Qui entrano in gioco firewall, routing, anti-spoofing o provider. Terzo: il secondo IP funziona solo in uscita o solo in ingresso. Qui il problema è quasi sempre la source address selection o una policy di rete non allineata.

Per distinguerli in pochi minuti, usa un test secco:

curl -4 -I http://192.0.2.20
ss -lntup | grep -E ':(80|443|22)\s'

Se curl fallisce ma il socket è in ascolto, il blocco è fuori dal processo: firewall, policy o rete. Se il socket non c’è, l’app non sta bindando sull’IP corretto.

Rollback pulito

Il rollback deve essere immediato e senza ambiguità. Se hai usato il metodo runtime, rimuovi l’IP con ip addr del. Se hai usato Netplan, ripristina il file di backup e riapplica la configurazione. Se hai toccato anche il pannello del provider, annulla lì la registrazione dell’IP aggiuntivo prima di fare debug lato OS, altrimenti insegui un problema che non è più locale.

sudo cp /etc/netplan/01-netcfg.yaml.bak /etc/netplan/01-netcfg.yaml
sudo netplan apply

Assunzione: l’interfaccia è già stata identificata correttamente e il secondo IP appartiene alla stessa rete o allo stesso schema di routing previsto dal provider.