Ti è mai capitato di riaccendere una macchina virtuale Ubuntu su VMware ESXi rimasta spenta per mesi o per un anno intero, e scoprire che non prende più la rete per nessun motivo, restituendo l’odioso errore “Nessun istradamento per l’host” (No route to host)?
Se i parametri di rete (IP statico, Subnet e Gateway) sono assolutamente corretti e non occupati da altri dispositivi, il problema risiede in un mix di saturazione dell’hardware virtuale e autodifesa del sistema operativo.
Controllare anche con una scansione di rete se l’indirizzo destinato alla VM Ubuntu è disponibile e quindi non assegnato a un altro host.
Prima di andare avanti, dovete essere sicuri che l’host abbiamo la rete giusta! Esempio : Rete > 192.168.1.X la subnet 255.255.255.0 ( o /24) e che il gateway sia chi fa da router che può essere un firewall o un router casalingo per fare aggiornamenti e uscire su internet.
Per una scansione di rete potete utilizzare questo software
https://www.advanced-ip-scanner.com/it/ e verificare tutti i dispositivi connessi alla rete scansionata.
In questa guida vedremo una checklist completa per il troubleshooting, ordinata dalla soluzione più semplice a quella più complessa.
LIVELLO 1: Verifiche su VMware ESXi (Il livello hardware virtuale)
Quando una VM rimane spenta a lungo in un ambiente di produzione, la causa del blocco risiede quasi sempre nell’infrastruttura dell’host o del vSwitch.
1. Il vSwitch o il Port Group è saturo (Slot Esauriti)
Nelle reti server aziendali, i Virtual Switch o i Port Group vengono spesso configurati con un numero fisso di porte attive per motivi di sicurezza o licenza. Se durante l’anno di inattività della tua VM altre macchine virtuali sono state accese o migrate, hanno occupato gli slot liberi.
- Cosa succede: La VM si accende, ma ESXi non ha una porta fisica virtuale da assegnarle. La VM rimane in uno stato “orfano” e non appare visivamente collegata nella mappa topologica del vSwitch di ESXi.
- Come risolvere:
- Controllare se la scheda di rete è attiva e c’è la spunta connetti all’accensione e quale scheda prende, nel nostro caso “Network“.
- Su ESXi vai in Networking o Servizi di rete➡️ Virtual Switches (o Port Groups).
- Controlla quante reti e quali assegnate alle VM sono sullo switch virtuale.
- Possiamo controllare quali macchine sono sullo vSwith0 in questione e a quali reti sono assegnate.(Segna 4 di reti).
- Se trovate la rete Network di esempio satura 4/4 VM assegnate (anche se uno di loro è spenta occupa uno slot dello switch virtuale) o rimuovete le VM che non utilizzate per assegnare la VM che vi sta dando il problema di prendere l’indirizzo IP o create un altra rete su VMWare ESXI per assegnarla alla VM dipende molto dall’esigenze.
2. Le Politiche di Sicurezza del Port Group
I sistemi Linux (specialmente se configurati con l’adattatore performante VMXNET3) gestiscono i pacchetti in modo rigido. Se i parametri interni divergono anche di poco da quelli registrati dall’host, il traffico viene troncato sul nascere.
- Come risolvere: Vai nelle impostazioni del Port Group su ESXi, clicca su Edit ➡️ Security e imposta temporaneamente su Accept (Accetta) le voci Promiscuous mode, MAC address changes e soprattutto Forged transmits.
N.B Dopo ogni modifica prova a riavviare la VM.
🟨 LIVELLO 2: Controlli all’interno del Sistema Operativo (Linux CLI)
Se l’hardware virtuale è sbloccato ma la VM continua a non comunicare, la colpa è dei conflitti software generati da NetworkManager o Netplan.
3. Il mistero della “Metrica 20100” nella Tabella di Routing
Se lanci il comando ip route show nel terminale e noti una configurazione di questo tipo:
default via 192.168.1.1 dev ens160 proto static metric 20100192.168.1.0/24 dev ens160 proto kernel scope link src 192.168.1.20 metric 100
N.B il nome ens160 non è sempre lo stesso su tutti gli host dopo il lancio del comando “ip router show” vedrete le schede di rete e le route dell’host ubuntu.
Significa che Ubuntu ha applicato la metrica corretta (100) all’interfaccia locale, ma ha assegnato una metrica penalizzante a 20100 (priorità bassissima) alla rotta di default. Il sistema operativo rileva che il cavo virtuale non scambia dati bidirezionali e declassa la scheda isolandola.
- Soluzione immediata (Temporanea): Rimuovi la rotta errata e forza quella corretta da terminale:
sudo ip route del default via 10.20.30.1 dev ens160 metric 20100 sudo ip route add default via 10.20.30.1 dev ens160 proto static metric 100Usa il codice con cautela.
- Soluzione definitiva (Netplan): Evita i bug della GUI sovrascrivendo la configurazione direttamente nel file principale di Netplan
-
sudo nano /etc/netplan/01-network-manager-all.yaml - . Incolla questa struttura formattata usando solo gli spazi (no TAB):yaml
network: version: 2 renderer: networkd ethernets: ens160: dhcp4: false dhcp6: false addresses: - 10.20.30.50/24 routes: - to: default via: 10.20.30.1 metric: 100 nameservers: addresses: - 10.20.30.10netplan apply
-
NB. quando scrivi dentro NetPlan si deve essere molto precisi negli spazi questo sopra è solo un esempio ma non posso replicare in modo fedele la sintassi e spazi. Per una corretta sintassi controlla la discussione in questo sito https://forum.ubuntu-it.org/viewtopic.php?t=627700 o fatti aiutare dall’IA.
🟥 LIVELLO 3: Sicurezza di Rete Fisica (Switch e Firewall)
Se il traffico non passa all’interno della stessa subnet locale (VLAN/Switch comune), l’inghippo risiede nell’invecchiamento dei record hardware sui dispositivi fisici.
Record ARP scaduti e Port Security sullo Switch Fisico
Gli switch fisici collegati agli host ESXi mantengono in memoria le tabelle MAC/CAM. Dopo un anno di silenzio, il MAC address della VM viene rimosso. Al riavvio improvviso, lo switch fisico potrebbe interpretare i pacchetti di quel vecchio MAC address come una minaccia (MAC Limiting o Port Security), bloccando il traffico a livello di porta fisica dell’host, ma è solo un ipotesi remota.
- Come risolvere: Cambia i connotati hardware della VM per costringere gli switch a reimparare il dispositivo come nuovo:
- Spegni la VM.
- Rimuovi la scheda di rete virtuale dalle impostazioni hardware su ESXi.
- Aggiungi un nuovo Network Adapter (tipo
VMXNET3) lasciando il MAC address in Automatico in modo da rinnovarlo. - Riaccendi la VM. Il nuovo indirizzo MAC bypasserà istantaneamente i vecchi record congelati nello switch fisico.
Seguendo questa checklist passo dopo passo, potrai diagnosticare con precisione millimetrica dove si interrompe il flusso di rete, riportando in produzione qualsiasi VM Linux rimasta in “letargo”.
Conclusione
Seguire una metodologia strutturata passo dopo passo permette di trasformare un problema di rete complesso in una serie di verifiche logiche e sequenziali.
Il problema da me è stato risolto controllando gli vSwitch virtuali e vedere effettivamente alla VM quale Rete era assegnata.
Se anche a voi è capitata una cosa del genere o avete risolto in altir modi scrivetemi nei commenti!
Rispondi