Da VMware NSX a Proxmox VE con SDN EVPN/VXLAN e router virtuali MikroTik

Il contesto

Un'azienda di servizi con due sale server gestisce circa duecentoquaranta macchine virtuali su sei host VMware vSphere 8. La rete è interamente virtualizzata con VMware NSX: trentotto segmenti overlay, un Tier-0 gateway in alta disponibilità che parla BGP con i router fisici, diversi Tier-1 gateway per separare ambienti di produzione, sviluppo e servizi esposti, NAT verso Internet, una VPN IPsec verso la sede secondaria e un distributed firewall con alcune centinaia di regole di microsegmentazione.

Il rinnovo VMware e NSX alle nuove condizioni non è sostenibile. Il team IT però considera NSX il motivo principale per cui "non si può" lasciare VMware: tutta la sicurezza interna dell'azienda è scritta lì.

L'obiettivo

Dimostrare, prima di decidere, che ogni funzione NSX effettivamente usata ha un equivalente funzionante su Proxmox VE. Poi migrare senza cambiare gli indirizzi IP delle macchine e senza abbassare il livello di segmentazione.

Come si traduce NSX

Il lavoro parte da un inventario completo della configurazione NSX: segmenti, gateway, rotte, sessioni BGP, regole NAT, tunnel VPN e regole del distributed firewall, con il traffico reale osservato per due settimane. Ogni oggetto viene associato al suo equivalente. La tabella completa, funzione per funzione, è nella pagina Da VMware NSX a Proxmox VE; qui la sintesi.

VMware NSX	Proxmox VE
Segmenti overlay (Geneve)	VNet dell'SDN di Proxmox VE in una zona EVPN con trasporto VXLAN
Tier-1 gateway distribuito	Gateway anycast dell'EVPN: ogni nodo instrada localmente per le sue VM
Tier-0 gateway e BGP verso i router fisici	Exit node del cluster in BGP con una coppia di MikroTik CHR in VRRP, che parlano BGP con i router fisici
Separazione tra ambienti (più Tier-1 e regole del gateway firewall)	Più zone EVPN, ognuna con la sua VRF e le sue regole di uscita
NAT, VPN IPsec verso la sede	NAT e IPsec sui MikroTik CHR di frontiera
Distributed firewall	Firewall di Proxmox VE a livello di VM, con security group, IPSet e alias

Segmenti e routing distribuito con EVPN e VXLAN

L'SDN di Proxmox VE gestisce le reti virtuali a livello di cluster. Una zona EVPN trasforma ogni segmento NSX in una VNet con la stessa subnet e lo stesso gateway; il traffico tra i nodi viaggia incapsulato in VXLAN sulla rete fisica esistente, e il piano di controllo è BGP EVPN, gestito da FRR su ogni nodo.

Come con il Tier-1 distribuito di NSX, il gateway di ogni subnet è presente su tutti i nodi con lo stesso indirizzo (gateway anycast). Una VM che parla con un'altra subnet viene instradata dal nodo su cui gira, senza passare da un router centrale, e dopo una live migration ritrova lo stesso gateway sul nuovo nodo.

In NSX gli ambienti stavano su Tier-1 diversi, ma sotto lo stesso Tier-0 si raggiungevano a livello di routing: a separarli erano le regole del gateway firewall. Su Proxmox VE diventano zone EVPN distinte, ognuna con la sua VRF. Produzione e sviluppo sono separati già nel routing: tra le zone passa solo il traffico permesso esplicitamente sui MikroTik CHR di frontiera.

Un'informazione da dare subito: Proxmox considera pienamente supportato il nucleo dell'SDN, mentre il routing con FRRouting su cui si basano le zone EVPN è ancora classificato come anteprima tecnologica nella documentazione ufficiale. È uno dei motivi per cui il progetto parte da una prova di fattibilità.

La frontiera: exit node e MikroTik CHR

Il traffico che esce dalle zone EVPN passa dagli exit node, due nodi Proxmox VE indicati nella configurazione della zona, e da lì a due router virtuali MikroTik Cloud Hosted Router (CHR), macchine virtuali con RouterOS su nodi diversi del cluster, separate da una regola di anti-affinità dell'alta disponibilità. I CHR ricevono in BGP dagli exit node le subnet delle VNet e le annunciano ai router fisici; in senso opposto passano agli exit node la rotta di default. Sui CHR ogni zona resta nella sua VRF.

Sui CHR girano anche il NAT verso Internet, la VPN IPsec verso la sede secondaria e il filtro del traffico in ingresso. La coppia è in alta disponibilità con VRRP, e sulle sessioni BGP è attivo BFD, anche sui router fisici: se un CHR o il suo nodo si ferma, l'altro prende gli indirizzi virtuali e i router fisici spostano il traffico in pochi secondi, invece di aspettare i tempi di BGP.

Microsegmentazione con il firewall di Proxmox VE

Il distributed firewall di NSX applica le regole sulla scheda di rete di ogni VM. Il firewall di Proxmox VE lavora allo stesso livello: le regole si applicano alla singola macchina virtuale, e si organizzano in security group riutilizzabili, con IPSet e alias come elenchi di indirizzi.

Le regole non vengono copiate una per una. Il traffico reale osservato nelle settimane precedenti mostra che circa un terzo delle regole NSX non viene mai usato. Le regole attive si raggruppano per ruolo (web, applicativo, database, gestione) in security group assegnati alle VM in base alla funzione. I gruppi dinamici di NSX, basati su tag o nomi, non hanno un equivalente diretto: diventano security group assegnati per ruolo e IPSet tenuti allineati dall'automazione. Il risultato è un insieme di regole più piccolo e più leggibile di quello di partenza.

Come è andata

Mese 1, inventario e prova di fattibilità. Esportazione della configurazione NSX e osservazione del traffico. In parallelo, un cluster Proxmox VE di tre nodi in laboratorio, con una zona EVPN, due exit node, due CHR e una copia delle regole di un ambiente. Il team IT verifica routing, failover dei CHR, live migration con mantenimento del gateway e applicazione delle regole firewall prima di approvare il progetto. Approvato il design, l'azienda ordina i server del nuovo cluster: le settimane di consegna non rientrano nel conteggio e servono a preparare il piano delle ondate.

Mese 2, costruzione e convivenza. Il nuovo cluster Proxmox VE viene installato accanto all'ambiente esistente e collegato agli stessi router fisici. NSX e la nuova rete convivono: i router ricevono le rotte da entrambi, e per ogni segmento migrato la rotta viene spostata dal Tier-0 NSX ai CHR nello stesso momento in cui si spostano le macchine.

Mesi 3 e 4, ondate per segmento. Si migra un gruppo di segmenti alla volta, insieme alle VM che li usano, mantenendo indirizzi IP e gateway invariati. Per le applicazioni non cambia nulla. Alla fine il Tier-0 NSX non annuncia più nessuna rotta e l'ambiente VMware viene spento.

Gli imprevisti

Le prime prove mostrano problemi solo con i pacchetti grandi: connessioni che si aprono ma si bloccano durante i trasferimenti. Le VM arrivano da NSX con MTU 1500, mentre una zona EVPN di Proxmox VE, se non si imposta diversamente, usa 1450, perché l'incapsulamento VXLAN aggiunge 50 byte. In più le interfacce di trasporto dei nuovi nodi sono rimaste a 1500. La rete fisica invece è già pronta, perché l'overlay Geneve di NSX richiedeva almeno 1600 byte. La soluzione è allineare l'MTU delle interfacce di trasporto dei nodi a quello degli switch, impostare 1500 sulle zone EVPN e verificare tutto con test end-to-end prima della prima ondata.

Una seconda sorpresa arriva da alcune regole NSX basate sui tag delle VM, che nessuno ricorda più. Il traffico osservato permette di ricostruirne lo scopo e tradurle in security group espliciti, documentati.

Il risultato

L'azienda lascia VMware vSphere e VMware NSX mantenendo segmentazione, routing dinamico, NAT, VPN e microsegmentazione. La rete è descritta nella configurazione dell'SDN di Proxmox VE e dei router MikroTik, entrambe salvate e versionate. I costi di licenza della rete si riducono alle sole licenze CHR, e il team gestisce routing e firewall con strumenti standard come BGP, VRRP e regole per VM, invece che con un prodotto proprietario.

Il punto più importante non è economico. La sicurezza interna non peggiora, e diventa più leggibile di prima.