Networking en VirtualBox para labs DevOps: la guía 2026
Si alguna vez levantaste una máquina virtual en VirtualBox y te encontraste con que no tenía internet, o que dos VMs no se veían entre sí, el problema casi siempre estuvo en la configuración de red. El networking en VirtualBox tiene tres modos principales (NAT, Bridged y Host-only) y cada uno resuelve un escenario distinto. Elegir mal te deja la VM aislada cuando la querías accesible, o expuesta cuando la querías encerrada.
El networking en VirtualBox es el sistema que define cómo una máquina virtual se conecta (o no) a internet, al host y a otras VMs. Cada VM tiene hasta cuatro adaptadores de red virtuales, y cada uno se configura en un modo: NAT, Bridged, Host-only o Internal. La metáfora que usa la guía de Ubayed Bin Sufian en dev.to es clara: cada adaptador es una puerta separada hacia la red.
En 30 segundos
- NAT es el modo por defecto: la VM sale a internet usando la IP del host, pero nadie de afuera la alcanza.
- Bridged conecta la VM a la red física, el router le da su propia IP y otros dispositivos la ven como una máquina más.
- Host-only arma una red privada entre el host y las VMs, sin salida a internet por defecto.
- Internal network conecta VMs entre sí sin pasar por el host, ideal para simular clusters.
- Cada VM soporta hasta 4 adaptadores: podés combinar modos (ponele NAT + Host-only) para tener internet y red privada a la vez.
¿Cuáles son los tres tipos principales de networking en VirtualBox?
Pensá en tu laptop. Cuando corrés ip addr en Linux casi nunca ves una sola interfaz. Ves lo (la interfaz loopback, 127.0.0.1, que es la máquina hablándose a sí misma), ves un puerto Ethernet cableado que quizás no tiene nada enchufado, y ves el Wi-Fi con una IP tipo 192.168.0.105/24 que te asignó el router por DHCP. Una computadora tiene varias puertas a la red. Las VMs funcionan igual, solo que las puertas son virtuales y vos elegís a dónde dan.
Los tres modos que vas a usar el 90% del tiempo son NAT, Bridged y Host-only. La decisión entre ellos se reduce a dos preguntas: ¿la VM necesita internet? ¿necesito que otras máquinas la alcancen? Acá la comparativa rápida antes de entrar en cada uno.
| Modo | Internet | Accesible desde la red física | Caso de uso típico |
|---|---|---|---|
| NAT | Sí | No | Desarrollo local aislado |
| Bridged | Sí | Sí | Servidor de testing en la LAN |
| Host-only | No (por defecto) | Solo el host y otras VMs | Lab privado sin salir afuera |
| Internal | No | Solo otras VMs | Simular un cluster cerrado |
¿Cómo funciona NAT en VirtualBox?
NAT (Network Address Translation) es el modo que viene activado por defecto cuando creás una VM. La máquina virtual queda detrás del host, como si estuviera detrás de un router casero. Tiene su propia IP privada interna (algo tipo 10.0.2.15) y cuando quiere salir a internet, VirtualBox traduce ese tráfico usando la conexión del host.
¿Para qué te sirve esto? Para desarrollar tranquilo. Levantás una VM, instalás dependencias, bajás paquetes, probás tu app, y la VM tiene internet sin que tengas que tocar nada. Es el modo seguro por defecto porque la VM puede salir pero nadie puede entrar. Relacionado: evitar exponer secretos en tus labs.
Eso sí: esa misma virtud es la limitación. Otras máquinas de tu red no pueden acceder a la VM. Si levantás un servidor web adentro y querés probarlo desde tu celular, NAT no te deja salvo que configures port forwarding a mano. Para un solo desarrollador trabajando local, NAT zafa perfecto. Para mostrarle algo a un colega en la misma oficina, te queda corto.
¿Cómo funciona Bridged networking?
Bridged es el otro extremo. Acá la VM se conecta directo a la red física del host, como si enchufaras un cable de red propio. El router le asigna una IP del mismo rango que el resto de tus dispositivos (ponele 192.168.0.120) y a partir de ahí la VM es un ciudadano más de la LAN.
El resultado es que cualquier dispositivo de la red la ve y la puede alcanzar. ¿Tenés un servidor de QA corriendo en la VM y el equipo lo quiere probar desde sus propias máquinas? Bridged. ¿Querés que la VM responda a un ping desde tu teléfono? Bridged.
Ahora bien, esa exposición tiene un costo. La VM queda visible en la red con todos sus puertos, y si adentro corre un servicio mal configurado, lo estás exponiendo a toda la LAN. En una red corporativa con políticas de seguridad, una VM en Bridged sin firewall propio es un agujero esperando a alguien. Usalo cuando necesitás accesibilidad real y tenés control de lo que corre adentro.
¿Cómo funciona Host-only networking?
Host-only arma una red privada cerrada entre el host y las VMs. Es como un cuartito sin ventanas: el host y las máquinas virtuales se hablan entre sí, pero por defecto no hay salida a internet. VirtualBox crea un adaptador virtual en el host (vboxnet0 en Linux y macOS) y todas las VMs en ese modo comparten ese segmento. Tema relacionado: testear tus pipelines de CI/CD.
El caso de uso clásico es testing de infraestructura que no querés que toque internet. Probás un setup de base de datos, una red de servicios internos, un entorno donde el aislamiento es la prioridad. La VM le habla al host y el host le habla a la VM, y listo, nada más sale de ahí.
¿Y si en algún momento necesitás que la VM también tenga internet? No tenés que abandonar Host-only. Le agregás un segundo adaptador en NAT. Así la VM queda con dos puertas: una para la red privada (Host-only) y otra para salir afuera (NAT). Esta combinación es de las más usadas en labs serios, porque te da aislamiento y conectividad sin elegir una sola.
¿Cómo configurar múltiples máquinas virtuales para que se comuniquen entre sí?
Acá viene lo bueno para cualquiera que arme labs de DevOps. Para que varias VMs se hablen entre ellas tenés dos opciones según cuánto aislamiento quieras.
Internal network: el cluster cerrado
Si querés que las VMs se vean entre sí pero ni siquiera el host las toque, usás Internal network. Le ponés el mismo nombre de red interna a cada adaptador (ponele “intnet-cluster”) y todas las VMs que compartan ese nombre quedan en el mismo segmento aislado. Es ideal para simular un cluster de Kubernetes local, una red de microservicios, o reproducir una red corporativa cerrada para practicar.
Host-only: cuando el host también juega
Si además del cluster querés que tu host pueda hacerle SSH a cada nodo o levantar un dashboard que vea las VMs, Host-only es mejor que Internal. Las VMs se ven entre sí y el host las ve a todas. Esto es lo más cómodo para desarrollar: gestionás los nodos desde tu máquina y las VMs siguen hablando entre ellas. Complementá con plataformas CI/CD para DevOps.
Un detalle práctico: en redes de varias VMs conviene asignar IPs estáticas en vez de depender de DHCP. Si cada nodo tiene una IP fija y conocida, tu inventario de Ansible, tu archivo de hosts o tu config de Kubernetes no se rompen cada vez que reiniciás. Acordate del límite: VirtualBox permite hasta 4 adaptadores por VM, así que podés combinar (ponele adaptador 1 en NAT para internet, adaptador 2 en Internal para el cluster).
¿Cómo resolver problemas comunes de conectividad?
La mayoría de los dolores de cabeza con redes en VirtualBox caen en tres categorías. Antes de tocar nada, abrí una terminal en la VM y corré ip addr (Linux) o ipconfig (Windows) para ver qué IP tiene realmente. La mitad de los problemas se diagnostican ahí.
| Síntoma | Causa probable | Qué revisar |
|---|---|---|
| La VM no tiene internet | Adaptador en Host-only o Internal sin NAT | Agregá un adaptador NAT; verificá DNS con ping 8.8.8.8 y después ping google.com |
| El host no ve la VM | Modo NAT (aísla la VM) | Cambiá a Host-only o Bridged, o configurá port forwarding |
| Las VMs no se ven entre sí | Distinto nombre de red interna o IPs en rangos distintos | Mismo nombre de Internal/Host-only y misma subred; probá ping entre ellas |
Un truco que ahorra tiempo: si ping 8.8.8.8 funciona pero ping google.com falla, no es problema de red, es DNS. El tráfico sale pero la VM no resuelve nombres. Revisá el /etc/resolv.conf en la guest. Diagnosticar la diferencia entre “no hay conexión” y “no hay DNS” te evita horas de tocar configuración de VirtualBox que estaba bien.
¿Qué configuración recomiendan para labs DevOps prácticos?
No hay una receta única, depende de qué estés armando. Estas son las combinaciones que más rinden según el escenario.
- Dev local de una sola VM: NAT + Host-only. Internet por NAT para bajar paquetes, Host-only para que tu host le haga SSH y pruebe servicios sin exponer nada a la LAN.
- Kubernetes o cluster local: Internal network aislada entre los nodos, más un adaptador NAT en cada uno para que bajen imágenes de contenedores. El plano de control y los workers se hablan por la red interna.
- Microservicios que deben verse desde otras máquinas: Bridged, para que cada servicio tenga IP real en la LAN y el equipo lo pruebe desde sus propias máquinas.
- Testing corporativo cerrado: Host-only puro, sin NAT, para reproducir una red sin salida a internet y probar cómo se comporta tu infra cuando está aislada.
Un ejemplo concreto: querés practicar un DNS local con tres VMs. Una hace de servidor DNS, las otras dos de clientes. Las ponés a las tres en Host-only con IPs estáticas (192.168.56.10, .11 y .12), configurás el DNS en la primera, apuntás las otras dos a esa IP, y tenés un lab funcional que no toca internet ni depende de tu router. Si después necesitás que el servidor baje un paquete, le sumás NAT como segundo adaptador y listo. Te puede servir nuestra cobertura de automatizar infraestructura con IA.
Para cuando ese lab tenga que salir de tu laptop y vivir en un servidor de verdad, ahí ya estás hablando de infraestructura cloud o VPS, y conviene mirar opciones de hosting como donweb.com para correrlo en un entorno con IP pública y disponibilidad real.
¿Cuáles son las limitaciones de VirtualBox para producción?
VirtualBox es excelente para aprender, prototipar y armar labs, pero no es para producción. El overhead de virtualización tipo 2 (corre sobre tu sistema operativo, no sobre el hardware directo) le pone un techo a la performance. Para cargas reales, el networking virtual se vuelve un cuello de botella.
Si necesitás escalar, las alternativas son hipervisores tipo 1 o nativos: KVM en Linux, Hyper-V en Windows, o Proxmox si querés una plataforma de virtualización completa para un datacenter. Y para producción de verdad, lo que hace la mayoría es ir directo a un proveedor cloud o un VPS donde la red, la IP pública y la disponibilidad ya vienen resueltas. Usá VirtualBox para lo que es bueno: dev, staging y practicar sin romper nada.
Errores comunes al configurar redes en VirtualBox
- Esperar que NAT permita acceder a la VM desde afuera. NAT aísla por diseño. Si necesitás que el host o la red alcancen la VM, usá Host-only o Bridged, o configurá port forwarding explícito. No es un bug, es el modo funcionando como debe.
- Poner las VMs en redes internas con nombres distintos. Dos VMs en Internal network solo se ven si comparten exactamente el mismo nombre de red. Un typo en “intnet” vs “intnet1” y las máquinas quedan en segmentos separados sin que entiendas por qué no se pingean.
- Confundir “no hay internet” con “no hay DNS”. Si la VM pinguea IPs pero no nombres de dominio, el problema es resolución de nombres, no conectividad. Mucha gente reinstala adaptadores cuando lo único roto era el resolv.conf.
- Olvidar que Host-only no da internet por defecto. Es la queja número uno de los que arrancan. Host-only es red privada, punto. Si querés internet también, sumá un segundo adaptador NAT.
Preguntas Frecuentes
¿Cuál es la diferencia entre NAT y Bridged en VirtualBox?
NAT le da internet a la VM pero la mantiene aislada: nadie de la red externa la puede alcanzar. Bridged conecta la VM directo a la red física, le asigna una IP propia del router y la hace visible para todos los dispositivos de la LAN. Usá NAT para desarrollo aislado y Bridged cuando necesitás que otras máquinas accedan a la VM.
¿Cómo le doy internet a una VM en Host-only?
Host-only no da internet por defecto porque es una red privada. Para sumarle salida, agregá un segundo adaptador de red a la VM configurado en modo NAT. Así la VM queda con dos puertas: la red privada de Host-only y la conexión a internet por NAT.
¿Cuántos adaptadores de red soporta una VM en VirtualBox?
VirtualBox permite hasta 4 adaptadores de red por máquina virtual desde la interfaz gráfica. Cada uno se configura de forma independiente en cualquier modo (NAT, Bridged, Host-only o Internal), lo que te deja combinar conectividad y aislamiento en la misma VM.
¿Por qué mis VMs no se ven entre sí en Internal network?
La causa más común es que los adaptadores tienen nombres de red interna distintos. Para que dos VMs se comuniquen en Internal network deben compartir exactamente el mismo nombre de red y estar en la misma subred IP. Verificá también que tengan IPs en el mismo rango si las asignaste a mano.
¿VirtualBox sirve para producción?
No. VirtualBox es un hipervisor tipo 2 pensado para desarrollo, staging y labs de aprendizaje. Para producción conviene KVM, Hyper-V, Proxmox o directamente un VPS o cloud, donde la performance de red, la escalabilidad y la disponibilidad están resueltas a nivel de infraestructura.
Conclusión
El networking en VirtualBox se entiende mejor pensando en puertas: cada adaptador da a un lado distinto de la red. NAT para salir aislado, Bridged para ser visible en la LAN, Host-only para un cuartito privado con el host, e Internal para un cluster cerrado entre VMs. La clave para labs DevOps no es elegir uno, es combinarlos: NAT para bajar paquetes más Host-only o Internal para que las máquinas se hablen entre sí. Empezá con esa combinación, asigná IPs estáticas, y cuando algo no conecte acordate de distinguir entre “no hay red” y “no hay DNS” antes de tocar la configuración. Con eso armás clusters de Kubernetes, redes de microservicios o un DNS local sin gastar un peso en infraestructura mientras aprendés.
