Come trovare l'indirizzo IP di un guest in VirtualBox

In VirtualBox l’IP di un guest non si “trova” con un solo comando valido sempre. Dipende da come hai collegato la VM alla rete: NAT, bridge, host-only, rete interna, DHCP esterno o IP statico. La cosa utile non è memorizzare un trucco, ma capire da dove leggere l’indirizzo e come verificarlo senza andare a tentativi.

Se il guest deve essere raggiunto dalla macchina host, l’obiettivo pratico è uno di questi: ottenere l’IP assegnato dal sistema operativo del guest, leggerlo dal lease DHCP del router o dell’host-only network, oppure fare una scansione mirata sulla sottorete corretta. Il metodo giusto cambia in base al tipo di adattatore configurato in VirtualBox.

Prima distinzione: che rete usa la VM

Apri le impostazioni della macchina virtuale in VirtualBox e controlla Rete. Lì trovi il dato che decide tutto: NAT, Bridge Adapter, Host-only Adapter, Internal Network o una combinazione di più schede.

Questa verifica è fondamentale perché l’IP del guest può essere visibile solo all’interno della VM, oppure anche dall’host, oppure ancora sul router della LAN. Se sbagli layer, perdi tempo con scansioni inutili o con comandi che non possono funzionare nel tuo scenario.

• NAT: il guest esce su Internet passando dal NAT di VirtualBox; dall’host non sempre è immediato vedere il suo IP interno.
• Bridge: la VM prende un IP dalla stessa rete del router; spesso è il caso più semplice da osservare dal DHCP della LAN.
• Host-only: la VM è visibile solo dall’host e da altre VM sulla rete host-only.
• Internal Network: la VM parla solo con altre VM della stessa rete interna; l’host non la vede direttamente.

Metodo più affidabile: leggere l’IP dentro il guest

Se hai accesso alla console della VM, questo è il metodo più pulito: interroghi l’interfaccia di rete del sistema operativo guest e prendi l’IP assegnato. Non dipendi dal router, dal NAT o da tool esterni.

Su Linux, il comando più pratico è questo:

ip addr show

Cerca l’interfaccia attiva, ad esempio enp0s3, eth0 o simili, e individua la riga con inet. L’IP appare nel formato 192.168.x.x/24 o equivalente.

Per estrarre solo l’indirizzo IPv4 puoi usare:

ip -4 addr show | grep -oP 'inet \K[^/ ]+'

Se vuoi vedere anche la route di default, utile per capire quale scheda è davvero usata dalla VM:

ip route

Su Windows guest, il comando classico è:

ipconfig

Su macOS guest:

ifconfig

Se il guest ha più interfacce, non fermarti al primo indirizzo che vedi. Controlla quale interfaccia ha la route di default o quale riceve il traffico utile. Un errore tipico è prendere l’IP della scheda secondaria che non è raggiungibile dalla tua postazione.

Se il guest è su rete bridged: controlla il DHCP del router

Con adattatore bridged il guest entra nella LAN come fosse un altro dispositivo fisico. In questo caso l’IP spesso lo trovi nella tabella DHCP del router o del firewall perimetrale.

Il vantaggio è che non devi entrare nella VM. Il limite è che serve un lease attivo e il router deve mostrarti il nome host, il MAC address o almeno l’IP assegnato.

• Apri il pannello del router.
• Vai nella sezione DHCP leases, client list o dispositivi connessi.
• Cerca il nome host della VM o il MAC address della scheda VirtualBox.
• Verifica che l’IP sia nella subnet della tua LAN, ad esempio 192.168.1.0/24.

Se il nome host non aiuta, il MAC address è spesso più affidabile. VirtualBox usa prefissi riconoscibili sulle schede virtuali, ma il valore esatto dipende dalla configurazione e non va dato per scontato. Il controllo corretto è incrociare MAC della VM e lease DHCP del router.

Se il guest è in NAT: l’IP interno non coincide con quello pubblico

Con NAT il guest riceve un indirizzo privato sulla rete virtuale di VirtualBox. Non è l’IP che il resto della LAN vede verso Internet, e non è neppure automaticamente raggiungibile dall’host su qualunque porta.

Qui la distinzione è netta: l’IP del guest esiste e lo leggi dentro la VM, ma il traffico in ingresso dall’esterno richiede port forwarding o un adattatore diverso. Se il tuo obiettivo è solo sapere l’IP interno, usa ip addr nel guest. Se invece vuoi raggiungerlo dall’host, devi sapere anche su quale sottorete NAT si trova.

Su VirtualBox, la rete NAT standard usa spesso una subnet privata del tipo 10.0.2.0/24, con gateway 10.0.2.2 e DNS 10.0.2.3. Non prenderla come valore universale: verifica nella configurazione della VM o dentro il guest con ip route e ip addr.

Se vuoi raggiungere il guest dall’host in NAT, la strada corretta è il port forwarding. Per esempio, puoi mappare la porta 2222 dell’host sulla 22 del guest per SSH. Questo non ti dà “l’IP visibile dall’host” nel senso classico, ma ti consente di lavorare in modo controllato senza cambiare la topologia.

Host-only: il caso più comodo per laboratori e test

Quando usi una rete host-only, VirtualBox crea una sottorete privata tra host e guest. È il caso ideale per fare test, perché il traffico resta confinato e l’host può vedere direttamente la VM.

In questo scenario l’IP del guest lo trovi in due modi: dentro la VM con ip addr oppure dal pannello di VirtualBox se la rete host-only ha un DHCP attivo e mostra i lease. In pratica, se la tua installazione è standard, la scoperta dell’IP è quasi immediata.

Su Linux host, puoi anche controllare l’interfaccia host-only creata da VirtualBox con:

ip addr show

Oppure, se vuoi vedere il dettaglio della rete VirtualBox:

VBoxManage list hostonlyifs

Per i lease DHCP gestiti da VirtualBox, un comando utile è:

VBoxManage list dhcpservers

Non tutti gli ambienti espongono DHCP host-only nello stesso modo, quindi il punto di verità resta il guest stesso. Se il router o il pannello non aiutano, entra nella VM e leggi l’IP dalla shell.

Rete interna: l’host non può vedere il guest

Con Internal Network la VM è isolata dall’host. Questo è utile per simulare segmenti di rete chiusi, ma cambia il modo in cui recuperi l’IP. Qui non ha senso guardare il router o l’host, perché non fanno parte della stessa rete.

In questo caso il metodo corretto è accedere al guest tramite console VirtualBox e interrogare direttamente il sistema operativo. Se hai più VM sulla stessa rete interna, puoi usare anche un secondo guest come punto di osservazione, ad esempio con ping o arp sulla stessa subnet.

Per test rapidi da un’altra VM della stessa rete:

ping 192.168.56.10

Se il ping fallisce, non assumere subito che l’IP sia errato. Potrebbe essere il firewall del guest a bloccare ICMP, oppure la rete interna potrebbe non essere configurata con la stessa label sulle due VM.

Se non puoi entrare nel guest: scansione mirata della subnet

Quando il guest è acceso ma non hai accesso alla shell, puoi fare una scansione della subnet giusta. È una tecnica pratica, ma va usata con criterio: prima devi sapere qual è la rete prevista, altrimenti scansioni a vuoto o, peggio, una rete sbagliata.

Uno strumento classico è nmap. Se sai che la VM sta nella rete 192.168.56.0/24:

nmap -sn 192.168.56.0/24

Questo fa discovery degli host attivi senza toccare porte applicative. Se vuoi anche identificare il MAC vendor, utile per riconoscere VirtualBox o l’host corretto, puoi aggiungere l’output dettagliato:

nmap -sn -oN scan.txt 192.168.56.0/24

Se la rete è bridged e sospetti che il guest abbia preso un IP dalla LAN, una scansione della subnet del router può aiutare, ma solo se la rete è piccola e controllata. In ambienti più grandi è meglio leggere il lease DHCP o accedere al guest.

Una verifica spesso più affidabile della sola scansione è cercare il MAC address nel router o fare ARP scan dalla stessa rete:

arp -a

Il limite è noto: ARP mostra solo dispositivi già visti sulla rete locale. Se il guest non ha ancora parlato, potresti non trovarlo subito.

Metodo da pannello: dove guardare in VirtualBox

Se preferisci l’interfaccia grafica, VirtualBox ti permette di verificare diversi elementi senza aprire la shell.

• Impostazioni della VM → Rete: controlli il tipo di adattatore e il MAC address.
• Gestione reti host-only: se usi host-only, puoi vedere la subnet associata.
• DHCP server: in alcune configurazioni puoi verificare i lease assegnati.

Il pannello è utile quando devi ridurre gli errori operativi, soprattutto se lavori su più VM simili. Invece di ricordarti il nome del device o il comando giusto, confronti direttamente MAC, tipo di adapter e subnet associata.

Come evitare il classico errore dell’IP cambiato

Il problema più comune non è trovare l’IP una volta sola, ma ritrovarlo dopo un reboot. Se la VM usa DHCP, l’indirizzo può cambiare. Questo vale soprattutto in bridged e host-only con pool dinamico.

Se l’IP ti serve in modo stabile, hai tre strade:

1. Impostare una prenotazione DHCP sul router o sul server DHCP usando il MAC address della VM.
2. Configurare un IP statico nel guest, coerente con la subnet e fuori dal pool dinamico.
3. Usare un meccanismo di service discovery o un nome DNS locale invece dell’IP hardcoded.

La terza opzione è spesso la migliore se il guest ospita servizi che devono essere raggiunti da altri sistemi. Un IP statico funziona, ma un nome stabile riduce gli incidenti quando l’ambiente cresce.

Se scegli un IP statico, verifica nel guest che la subnet, il gateway e i DNS siano coerenti. Un indirizzo assegnato male può “sembrare vivo” ma non uscire dalla rete o non risolvere i nomi. Il controllo minimo è sempre questo:

ip addr show
ip route
resolvectl status

Risoluzione rapida dei casi ambigui

Se non sai da dove partire, usa questa sequenza. È veloce e ti dice subito quale layer è rotto o semplicemente invisibile.

1. Apri la console del guest e lancia ip addr o ipconfig.
2. Controlla in VirtualBox il tipo di rete della scheda virtuale.
3. Se è bridged, cerca il lease nel router.
4. Se è host-only, verifica la subnet host-only e i lease DHCP.
5. Se è NAT e ti serve solo il traffico in uscita, considera il port forwarding invece della ricerca dell’IP dall’esterno.

In pratica, il 90% delle volte l’IP è già visibile dentro il guest. Il resto è quasi sempre un problema di topologia: stai cercando l’indirizzo nel posto sbagliato rispetto al tipo di rete scelto.

Esempio operativo: VM Linux in bridged su rete domestica

Scenario tipico: hai una VM Linux in bridge, il router assegna gli indirizzi via DHCP e vuoi trovare l’IP per fare SSH.

1. Apri la console della VM e controlla l’interfaccia con ip addr show.
2. Se l’IP è 192.168.1.74, prova dal tuo host:

ping 192.168.1.74
ssh user@192.168.1.74

Se il ping risponde ma SSH no, il problema non è l’IP: è il servizio SSH, il firewall del guest o le chiavi di accesso. Se invece non risponde nulla, verifica la route, il bridge e il lease DHCP.

Se vuoi rendere il risultato stabile, configura una reservation DHCP sul router per il MAC della VM. Così l’IP resta lo stesso dopo i riavvii senza dover toccare la configurazione di rete del sistema operativo guest.

Esempio operativo: VM Ubuntu in NAT con bisogno di accesso SSH

Scenario diverso: la VM è in NAT e vuoi solo entrarci da host. In questo caso cercare l’IP “esterno” non ha senso. La soluzione pulita è usare il port forwarding.

Nel pannello VirtualBox, sotto Rete → Avanzate → Port forwarding, crea una regola del tipo:

Host Port: 2222
Guest Port: 22

Poi dal tuo host accedi con:

ssh -p 2222 user@127.0.0.1

Qui l’IP del guest resta utile solo per diagnostica interna. Per il lavoro quotidiano usi il loopback dell’host e la porta inoltrata. È un approccio più robusto di inseguire un indirizzo che, in NAT, non è pensato per essere raggiunto direttamente.

Checklist finale da tenere in tasca

Se devi trovare rapidamente l’indirizzo IP di un guest VirtualBox, la checklist pratica è questa:

• Controlla il tipo di rete della VM in VirtualBox.
• Se puoi, entra nel guest e usa ip addr o ipconfig.
• Se è bridged, verifica il lease nel router.
• Se è host-only, controlla la subnet host-only e i lease DHCP.
• Se è NAT, non cercare un IP raggiungibile dall’host: usa port forwarding.
• Se l’IP cambia troppo spesso, passa a reservation DHCP o IP statico documentato.

La regola pratica è semplice: prima capisci il layer di rete, poi leggi l’IP nel posto giusto. VirtualBox non nasconde l’indirizzo; spesso è solo il contesto a renderlo meno ovvio del previsto.