51 05/04/2026 07/04/2026 10 min

Obiettivo e architettura

Se vuoi dare connettività agli ospiti da un nodo Proxmox, la scelta corretta è separare la rete guest dalla rete di management. Il punto non è solo “far prendere un IP”, ma evitare che una VM ospite possa vedere l’infrastruttura di amministrazione, le VM interne o i servizi di storage.

Il modello più pulito è questo: una rete Layer 2 dedicata per gli ospiti, un bridge Linux su Proxmox collegato a una NIC fisica o a una VLAN dedicata, e un server DHCP che distribuisce indirizzi solo su quella subnet. Il DHCP può girare su una VM o su un container LXC; in molti casi è meglio tenerlo fuori dall’host Proxmox, così il piano di controllo resta separato dal piano servizi.

Se hai un solo host Proxmox e una sola porta fisica, puoi comunque fare tutto con VLAN tagging. Se hai più NIC, puoi usare una NIC per management e una per guest. In entrambi i casi la regola è la stessa: il bridge guest non deve essere “ponte” verso la rete di management senza filtraggio.

Scelta della topologia: bridge fisico o VLAN

Hai due opzioni pratiche.

  • Bridge dedicato su NIC separata: semplice da capire, ottimo se hai abbastanza porte fisiche. La NIC guest va in un bridge tipo vmbr1, la management resta su vmbr0.
  • VLAN su bridge trunk: una sola NIC porta più reti. Il bridge Proxmox trasporta le VLAN e le VM vengono collegate con VLAN tag specifico. È più flessibile, ma richiede disciplina sulla configurazione degli switch e delle VM.

Per una rete ospiti, la VLAN dedicata è spesso la soluzione migliore: isola bene, si documenta facilmente e ti consente di spostare in futuro il DHCP o aggiungere un firewall senza rifare il cablaggio.

Prerequisiti minimi

Prima di toccare la configurazione, verifica questi punti:

  • Hai accesso console o IPMI al nodo Proxmox, così non rischi di perdere la gestione remota.
  • Conosci la subnet guest che vuoi usare, per esempio 192.168.50.0/24.
  • Hai deciso chi fa da gateway e chi fa da DHCP: router/firewall, VM dedicata, o container dedicato.
  • Hai un piano di rollback: snapshot della VM DHCP, backup di /etc/network/interfaces sul nodo, e eventuale accesso locale in caso di errore di rete.

Se stai lavorando su un host in produzione, la finestra di change va trattata come rischio reale: una modifica errata al bridge può tagliare fuori anche la management network.

Configurazione del bridge guest su Proxmox

Su Proxmox, la configurazione rete è tipicamente in /etc/network/interfaces. Il concetto è creare un bridge separato per la rete ospiti oppure una VLAN-aware bridge se usi trunk.

Esempio con bridge dedicato su NIC separata:

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.0.0.10/24
    gateway 10.0.0.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

auto vmbr1
iface vmbr1 inet manual
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0

Qui vmbr0 è la management network e vmbr1 è la rete ospiti. Le VM guest si collegano a vmbr1. Se vuoi che il DHCP stia sulla stessa rete, assegni al server DHCP una NIC virtuale collegata a vmbr1.

Esempio con VLAN-aware bridge:

auto vmbr0
iface vmbr0 inet static
    address 10.0.0.10/24
    gateway 10.0.0.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

In questo caso lo switch a monte deve passare le VLAN necessarie. La VM DHCP e le VM ospiti useranno un tag VLAN coerente, per esempio VLAN 50 per la rete guest.

Prima di applicare modifiche al file di rete, fai sempre una copia:

cp /etc/network/interfaces /etc/network/interfaces.bak.$(date +%F-%H%M)

Se usi Proxmox VE, puoi anche verificare la configurazione lato GUI in Node > System > Network. Questo riduce errori di sintassi, ma il file resta la fonte operativa da controllare.

Dove far girare il DHCP

Le opzioni sane sono tre.

  1. Router/firewall: se hai già un firewall tipo OPNsense, pfSense, MikroTik o un router Linux, lascia lì il DHCP. È spesso la soluzione più semplice e robusta.
  2. VM dedicata: utile se vuoi tenere il servizio separato dal firewall o se il firewall non deve gestire le reti ospiti.
  3. Container LXC dedicato: leggero e comodo, ma va gestito con attenzione ai privilegi e alle interfacce di rete.

Se l’obiettivo è una rete ospiti semplice, la VM dedicata è spesso il compromesso migliore: isolamento chiaro, backup facile, upgrade indipendente. Il container va bene se hai già standardizzato la gestione dei servizi di rete in LXC.

Configurare un DHCP server semplice con ISC Kea o dnsmasq

Per una rete ospiti, i due approcci più comuni sono Kea DHCP o dnsmasq. Kea è più moderno e strutturato; dnsmasq è più leggero e veloce da configurare. Se ti serve solo un range DHCP semplice, dnsmasq è spesso sufficiente. Se vuoi logging più pulito, opzioni avanzate e struttura JSON, Kea è preferibile.

Esempio concettuale con dnsmasq su una VM Linux collegata alla rete guest:

interface=eth0
bind-interfaces
except-interface=lo
dhcp-range=192.168.50.100,192.168.50.200,255.255.255.0,12h
dhcp-option=option:router,192.168.50.1
dhcp-option=option:dns-server,192.168.50.1,1.1.1.1
log-dhcp

In questo caso:

  • eth0 è la NIC della VM collegata alla rete guest;
  • 192.168.50.1 è il gateway della subnet guest;
  • il range DHCP è 192.168.50.100-200;
  • il lease è di 12 ore.

Se usi Kea, la logica è identica: definisci interfaccia, subnet, pool e opzioni. La differenza è il formato della configurazione e la gestione del servizio. Il vantaggio è che Kea scala meglio e si integra bene con logging e backend esterni.

Se il DHCP gira su una VM, configura la NIC della VM come collegata esclusivamente a vmbr1 o alla VLAN guest. Non mettere la stessa VM anche sulla management network, a meno che tu non abbia un motivo preciso e un firewall interno rigoroso.

Impostare gateway, DNS e isolamento

Il DHCP non basta: la rete ospiti deve avere un gateway chiaro e un perimetro di accesso definito. La subnet guest dovrebbe poter uscire verso Internet, ma non raggiungere la rete di management, le reti storage o le VM interne.

Le opzioni DHCP da distribuire normalmente sono:

  • router/gateway della subnet guest;
  • DNS resolver autorizzato;
  • dominio di ricerca, se serve;
  • lease time coerente con l’uso ospiti.

Se hai un firewall a monte, crea una policy esplicita:

  • allow guest -> Internet;
  • deny guest -> management subnet;
  • deny guest -> storage subnet;
  • allow guest -> DHCP server solo sulla porta 67/UDP, se il server non è nello stesso segmento L2.

Se il server DHCP è nella stessa VLAN L2 dei client, il traffico DHCP non attraversa routing e il firewall interviene meno. Questo è un buon motivo per tenere DHCP e client nella stessa rete di broadcast, ma sempre separata dal resto dell’infrastruttura.

Configurazione lato VM o container

Su Proxmox, quando crei la VM DHCP, assegna una scheda di rete collegata al bridge guest. In GUI, il percorso tipico è VM > Hardware > Add > Network Device. Scegli il bridge corretto e, se usi VLAN, imposta il tag giusto.

Checklist operativa:

  • driver di rete stabile, per esempio VirtIO;
  • IP statico del server DHCP nella subnet guest, fuori dal pool dinamico;
  • default gateway corretto;
  • DNS coerente con la policy della rete ospiti;
  • servizio DHCP abilitato all’avvio.

Se il server usa un IP statico, tienilo fuori dal range DHCP. Per esempio, se il pool è 192.168.50.100-200, assegna al server 192.168.50.2 o simile. Questo evita conflitti di lease.

Verifiche operative dopo il deploy

Le verifiche vanno fatte in ordine di layer: link, L2, DHCP, routing, DNS, uscita Internet.

  1. Controlla che il bridge sia UP sul nodo Proxmox: ip link show vmbr1. Atteso: stato UP.
  2. Verifica che la VM DHCP sia collegata al bridge corretto: da GUI o con qm config <VMID>. Atteso: net0 su vmbr1 o VLAN giusta.
  3. Dal client guest, rinnova il lease: dhclient -r && dhclient -v oppure riattiva la scheda di rete. Atteso: IP della subnet guest.
  4. Controlla il lease sul server DHCP: file lease o log del servizio. Atteso: MAC, IP assegnato, tempo lease.
  5. Prova il gateway: ping -c 3 192.168.50.1. Atteso: risposta stabile.
  6. Prova la risoluzione DNS: nslookup example.com o dig example.com. Atteso: risposta valida.
  7. Prova l’uscita: curl -I https://example.com. Atteso: HTTP 200/301, nessun timeout.

Se il client riceve un IP ma non naviga, il problema è di solito routing o firewall, non DHCP. Se non riceve nulla, il problema è quasi sempre bridge, VLAN, scope o servizio DHCP non in ascolto.

Errori tipici e come riconoscerli

Ci sono alcuni errori ricorrenti che vale la pena riconoscere subito.

  • Bridge sbagliato: la VM DHCP è su vmbr0 invece che su vmbr1. Sintomo: i client non vedono il lease o prendono IP della rete sbagliata.
  • VLAN tag incoerente: la VM guest è taggata VLAN 50, ma lo switch o il bridge non passano quella VLAN. Sintomo: link up ma nessun traffico utile.
  • Pool sovrapposto: il range DHCP include IP già usati da server o stampanti. Sintomo: conflitti di indirizzo e instabilità casuale.
  • Gateway errato: i client ottengono IP, ma non escono. Sintomo: ping al gateway fallisce o default route assente.
  • Firewall troppo stretto: DHCP funziona, ma il traffico UDP/TCP verso DNS o Internet è bloccato. Sintomo: IP assegnato, ma niente risoluzione o navigazione.

La diagnosi corretta si fa sempre dal basso verso l’alto: prima connettività L2, poi lease, poi routing, poi policy.

Hardening minimo per una rete ospiti

Una rete ospiti non dovrebbe mai essere trattata come una LAN interna. Anche se è “solo per i visitatori”, conviene applicare un set minimo di controlli.

  • Separazione netta da management e storage.
  • DHCP con scope limitato e lease non troppo lunghi.
  • DNS filtrato o resolver controllato, se vuoi ridurre abuso e phishing.
  • Firewall con deny esplicito verso subnet interne.
  • Logging del DHCP per audit minimo, senza conservare dati inutili oltre il necessario.

Se la rete ospiti usa internet condiviso con altre reti, valuta anche rate limit o policy QoS sul firewall. Non è obbligatorio per il DHCP, ma aiuta a evitare che una sala piena di dispositivi saturi la banda.

Backup e rollback

Ogni change su Proxmox che tocca rete o DHCP deve avere rollback pronto. Il rollback tipico è semplice:

  1. Ripristina il file /etc/network/interfaces dalla copia di backup se il bridge è stato modificato male.
  2. Riavvia il servizio networking solo se hai console locale o accesso OOB, altrimenti applica con estrema cautela.
  3. Se la VM DHCP è stata toccata, ripristina snapshot o backup della VM.
  4. Se hai cambiato firewall o VLAN, annulla la regola o il tag errato prima di fare ulteriori prove.

Se stai lavorando in produzione, la regola pratica è: prima osservazione, poi cambiamento minimo, poi verifica. Mai fare insieme bridge, DHCP e firewall senza un punto di ripristino.

Schema consigliato per partire bene

Se vuoi una configurazione solida e semplice, parti così:

  • Proxmox con management su vmbr0.
  • Rete guest su vmbr1 o VLAN dedicata.
  • VM DHCP dedicata con IP statico nella subnet guest.
  • Firewall che permette solo uscita controllata dalla guest.
  • Range DHCP limitato, gateway e DNS espliciti.

Questa architettura è facile da mantenere, facile da documentare e abbastanza robusta per un ambiente piccolo o medio. Se in seguito vuoi aggiungere captive portal, controllo accessi o segmentazione per dipartimenti, hai già la base giusta.

Assunzione: qui si parte da un nodo Proxmox già operativo, con accesso console e possibilità di assegnare una rete guest separata tramite bridge o VLAN.

Verifica finale veloce

Prima di dare il change per chiuso, controlla queste tre cose:

  1. Un client guest ottiene un IP corretto dalla subnet prevista.
  2. Il client raggiunge il gateway e risolve DNS.
  3. La rete guest non raggiunge la rete di management.

Se questi tre punti sono veri, il DHCP su Proxmox per gli ospiti è configurato in modo corretto e soprattutto non sta aprendo buchi inutili nell’infrastruttura.