Configurare una rete instradata su Proxmox VE 8

Obiettivo e scenario

Su Proxmox VE 8 una rete instradata serve quando vuoi far passare una o più VM/CT su una subnet dedicata, raggiungibile dal resto della rete tramite routing, senza dover estendere il dominio L2 con un bridge “aperto” verso la LAN fisica. È il caso tipico di ambienti lab, hosting di servizi isolati, segmentazione per clienti o separazione tra management, storage e workload.

Il punto chiave è questo: Proxmox non fa routing automaticamente. Il nodo deve avere una configurazione di rete coerente, IP forwarding attivo e regole firewall/masquerade se la subnet non è annunciata a monte. Se la rete è già instradata dal router principale, la configurazione è più pulita. Se invece vuoi che il nodo faccia da gateway per le VM, devi impostare il forwarding e, se serve, il NAT.

Qui uso un esempio concreto:

• rete management del nodo: 192.168.1.0/24
• rete instradata per le VM: 10.10.10.0/24
• gateway della rete VM: 10.10.10.1 sul nodo Proxmox

La procedura è valida anche se i numeri cambiano. Cambiano solo gli indirizzi, non il modello.

Architettura consigliata

La soluzione più pulita su Proxmox VE 8 è usare un bridge Linux dedicato alla subnet instradata, senza collegarlo fisicamente a una NIC uplink se non ti serve L2 esteso. Le VM si attaccano a quel bridge e usano l’IP del nodo come gateway. Il nodo poi instrada verso la LAN o verso Internet tramite la sua interfaccia principale.

Due casi pratici:

1. Routing puro: la subnet 10.10.10.0/24 è annunciata sul router a monte con una route statica verso l’IP del nodo Proxmox sulla LAN. È la scelta migliore se vuoi raggiungibilità bidirezionale corretta senza NAT.
2. Routing con NAT: il router a monte non può o non vuole conoscere la subnet VM. Il nodo fa masquerade verso la LAN/Internet. È più veloce da mettere in piedi, ma meno pulito e meno trasparente per i servizi in ingresso.

Se puoi scegliere, preferisci il routing puro. Il NAT usalo solo quando il contesto lo impone.

Configurazione di rete sul nodo Proxmox

La rete di Proxmox si definisce in /etc/network/interfaces oppure via GUI in Node > System > Network. La GUI è comoda per ridurre errori, ma il file finale resta la fonte reale della configurazione.

Esempio con bridge dedicato vmbr1 per la subnet instradata:

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

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

auto vmbr1
iface vmbr1 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0

In questo schema vmbr0 è il bridge verso la LAN fisica e vmbr1 è il gateway della rete VM. Le VM che devono stare nella subnet instradata useranno vmbr1 come NIC. Il nodo risponderà su 10.10.10.1 e farà routing tra vmbr1 e vmbr0.

Se stai usando bonding, VLAN o più NIC, il concetto non cambia: il bridge di management resta separato dal bridge della rete instradata. La differenza è solo dove agganci il traffico fisico.

Regola pratica: se una subnet deve essere instradata e non bridgeata a livello 2, non collegarla a una porta fisica “per abitudine”. Collega solo ciò che serve davvero.

Abilitare l’IP forwarding

Per instradare pacchetti il kernel deve accettare il forwarding IPv4. Verifica prima lo stato:

sysctl net.ipv4.ip_forward

Atteso: net.ipv4.ip_forward = 1. Se vedi 0, abilitalo in modo persistente:

echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-proxmox-routing.conf
sysctl --system

Verifica immediata:

sysctl net.ipv4.ip_forward

Se il valore resta 0, il problema è nel caricamento di sysctl o in un override successivo. Controlla con:

grep -R "ip_forward" /etc/sysctl.conf /etc/sysctl.d /usr/lib/sysctl.d 2>/dev/null

Questo è un cambiamento reversibile: basta rimuovere il file dedicato e ricaricare sysctl.

Routing puro: aggiungere la route sul router a monte

Se vuoi evitare NAT, il router o firewall principale deve sapere che la subnet 10.10.10.0/24 è raggiungibile passando per il nodo Proxmox. La route statica tipica è:

10.10.10.0/24 via 192.168.1.10

Dove 192.168.1.10 è l’IP del nodo sulla rete di management. Il punto importante è che il router deve avere una route verso il nodo, non verso il bridge interno. Il bridge interno non è visibile a monte.

Verifica da un host della LAN:

ip route get 10.10.10.10

Atteso: il traffico deve puntare verso il router che conosce la route per 10.10.10.0/24. Se invece il pacchetto va nel nulla o finisce su un gateway sbagliato, la route statica manca o è errata.

Su questa architettura le VM devono usare come gateway 10.10.10.1. Il router principale non deve fare NAT per la subnet interna; deve solo instradarla.

NAT: quando la route statica non è possibile

Se non puoi toccare il router principale, puoi fare masquerade sul nodo Proxmox. In questo caso la subnet VM esce verso la LAN/Internet usando l’IP del nodo. È una scorciatoia accettabile per lab o ambienti piccoli, meno ideale per servizi che devono essere raggiunti dall’esterno con IP propri.

Con nftables la logica minima è questa:

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.10.10.0/24 oifname "vmbr0" masquerade
  }
}

Devi anche consentire il forwarding tra interfacce. La parte filter, se il firewall è attivo, deve permettere il passaggio tra vmbr1 e vmbr0.

Verifica con:

nft list ruleset

e con una prova dalla VM:

curl -4 https://ifconfig.me

Atteso: l’IP pubblico o di uscita deve essere quello del nodo o del router a monte, non l’IP privato della VM. Se la richiesta si blocca, il problema è nella catena forward o nella policy di firewall.

Se usi il firewall integrato di Proxmox, ricorda che le policy del Datacenter, del nodo e della VM possono sommarsi. Un masquerade corretto non basta se il forwarding è bloccato a livello firewall.

Configurare le VM

Ogni VM che deve stare nella subnet instradata va collegata al bridge dedicato, per esempio vmbr1. Dentro la VM configuri un IP della rete 10.10.10.0/24, gateway 10.10.10.1 e DNS secondo la tua policy.

Esempio Linux nella VM:

IP: 10.10.10.10/24
Gateway: 10.10.10.1
DNS: 1.1.1.1 oppure resolver interno

Verifica dalla VM:

ip addr
ip route
ping -c 3 10.10.10.1
ping -c 3 192.168.1.1
ping -c 3 8.8.8.8

Atteso:

• 10.10.10.1 deve rispondere.
• La LAN deve essere raggiungibile se il routing è corretto.
• L’uscita Internet deve funzionare se hai route a monte o NAT.

Se il ping al gateway fallisce, il problema è quasi sempre uno tra: bridge errato nella VM, IP sbagliato, firewall sul nodo, o bridge del nodo non configurato come rete locale.

Firewall Proxmox: cosa controllare

Con reti instradate il firewall va trattato come parte del design, non come accessorio. Su Proxmox puoi avere policy a livello Datacenter, nodo e VM. Il rischio classico è fare la configurazione di routing giusta e poi bloccare il traffico nel firewall senza accorgersene.

Controlli rapidi:

pve-firewall status
systemctl status pve-firewall --no-pager

Se il firewall è attivo, verifica le regole e i log. Su sistemi standard i log sono in /var/log/syslog o nel journal di pve-firewall. Cerca drop o reject sulla subnet 10.10.10.0/24.

journalctl -u pve-firewall -n 100 --no-pager

Se usi regole custom, mantieni il principio di minima esposizione: consenti solo ciò che serve tra subnet instradata, management e Internet. Non aprire tutto “per farlo funzionare”.

Verifiche di rete dal nodo

Prima di colpevolizzare la VM, testa il nodo. È il modo più veloce per isolare il layer in errore.

ip addr show vmbr1
ip route
ping -c 3 10.10.10.10
arping -I vmbr1 10.10.10.10

Atteso:

• vmbr1 deve avere l’IP 10.10.10.1/24.
• La route per 10.10.10.0/24 deve essere connected via vmbr1.
• La VM deve rispondere a ping o almeno comparire nella tabella ARP se è accesa e senza filtri L3 interni.

Se il nodo non vede la VM, il problema è lato bridge, NIC virtuale o firewall della VM. Se il nodo vede la VM ma non esce, il problema è nel routing verso l’esterno o nel NAT.

Verifiche di rete dal router o da un host esterno

Se hai configurato una route statica, devi verificare il cammino completo. Da un host nella LAN prova:

traceroute 10.10.10.10
ping -c 3 10.10.10.10

Il traceroute deve passare dal router che conosce la route verso il nodo Proxmox e poi arrivare alla VM. Se si ferma al primo hop, la route non è installata. Se arriva al nodo ma non alla VM, il problema è nel forwarding o nel firewall del nodo.

Se usi NAT, il test corretto è da dentro la VM verso l’esterno. Un host nella LAN non deve necessariamente poter entrare nella subnet interna senza port-forward o route dedicata.

Errori tipici e come riconoscerli

Gateway sbagliato nella VM: la VM pinga il nodo ma non la LAN. Verifica ip route nella VM; default route deve puntare a 10.10.10.1.

IP forwarding disattivato: il nodo ha gli IP giusti ma non instrada. Verifica sysctl net.ipv4.ip_forward.

Firewall che blocca il forwarding: ping al gateway ok, traffico inter-subnet no. Controlla pve-firewall e le policy di nodo/Datacenter/VM.

Route statica mancante sul router a monte: la subnet è raggiungibile dal nodo, non dalla LAN. Verifica la tabella route del router o almeno il test con traceroute da un host interno.

Masquerade incompleto: la VM esce ma non riceve risposte. Verifica la chain NAT e la policy forward su nftables.

Procedura minima consigliata

1. Definisci la subnet instradata, per esempio 10.10.10.0/24, e assegna al nodo l’IP gateway 10.10.10.1 sul bridge dedicato.
2. Abilita net.ipv4.ip_forward=1 e verifica che resti attivo dopo reboot.
3. Se possibile, aggiungi una route statica sul router principale verso la subnet VM tramite l’IP del nodo.
4. Se la route statica non è possibile, configura masquerade con nftables sul nodo.
5. Collega le VM al bridge dedicato e imposta gateway e DNS corretti dentro ogni guest.
6. Testa dal nodo, poi dalla VM, poi da un host esterno alla subnet.

Controlli finali e rollback

Prima del go-live verifica questi punti minimi:

• sysctl net.ipv4.ip_forward restituisce 1.
• ip addr show vmbr1 mostra l’IP gateway corretto.
• La VM raggiunge il gateway e almeno un host della LAN.
• Se usi NAT, la VM esce verso Internet e il traffico di ritorno rientra.
• Se usi route statica, un host della LAN raggiunge la VM senza passare da NAT.

Rollback semplice:

1. Rimuovi o disabilita la route statica sul router a monte, se introdotta.
2. Disabilita temporaneamente il masquerade o le regole nftables aggiunte per il forwarding.
3. Rimuovi il file /etc/sysctl.d/99-proxmox-routing.conf se vuoi tornare allo stato precedente e ricarica sysctl.
4. Rimuovi il bridge dedicato solo se non è più referenziato da VM/CT e hai già migrato i guest.

Assunzione operativa: il nodo Proxmox ha una NIC di management separata o comunque un percorso stabile verso la LAN, e puoi modificare almeno il routing del gateway principale oppure accettare NAT sul nodo.

Nota pratica su Proxmox VE 8

Su Proxmox VE 8 la parte importante non è tanto la versione in sé, quanto l’integrazione tra ifupdown2, bridge Linux, firewall e routing del kernel. La GUI di Proxmox è comoda per creare bridge e assegnare IP, ma per le reti instradate conviene sempre tenere sotto controllo il file di configurazione e verificare che non ci siano conflitti con VLAN, bond o regole firewall già presenti.

Se stai lavorando in produzione, fai il cambio in finestra controllata: backup del file di rete, accesso console out-of-band o IPMI pronto, e una sessione secondaria aperta per non restare tagliato fuori dal nodo. La rete di management del nodo non va mai toccata senza una via di accesso alternativa.

In pratica: bridge separato, forwarding attivo, route o NAT coerenti, firewall allineato. Se questi quattro pezzi sono corretti, la rete instradata su Proxmox VE 8 è stabile e pulita da gestire.

Se vuoi, il passo successivo è adattare questo schema a un caso reale: una singola NIC, un bond, VLAN trunk, oppure una configurazione con subnet pubbliche e servizi esposti.