Entendiendo las redes en Docker: bridge, host y macvlan
La red en Docker siempre genera alguna duda
Si llevas un tiempo con Docker, probablemente ya tienes contenedores funcionando y los básicos controlados. Pero en algún momento aparece el momento incómodo: ¿por qué este contenedor no ve al otro si están en la misma máquina? ¿Por qué tengo que publicar puertos con -p si ya están corriendo juntos? ¿Cuándo tiene sentido macvlan y cuándo es matar moscas a cañonazos?
No es que hayas hecho algo mal. Es que Docker tiene varios modos de red con diferencias reales que no quedan claras leyendo la documentación de pasada. Bridge, host, macvlan… cada uno resuelve un problema distinto, y elegir el equivocado en un homelab o en un proyecto que quieres dejar estable te puede costar un buen rato de debug innecesario.
En este post vamos al grano: qué hace cada modo, cuándo toca usarlo y qué limitaciones necesitas conocer antes de decidirte. Con ejemplos del tipo de proyectos que probablemente estás montando, no con teoría de red abstracta.
Por qué importa
DNS solo en bridge propio
Las redes user-defined tienen servidor DNS en 127.0.0.11. La red docker0 por defecto no resuelve contenedores por nombre.
Host: sin NAT, solo Linux
El contenedor comparte la pila de red del host directamente. En Docker Desktop (Mac/Windows) hay una VM intermedia: el efecto no es el mismo.
macvlan pide modo promiscuo
Hace al contenedor aparecer como dispositivo físico en tu LAN, pero la interfaz del host debe estar en modo promiscuo.
ipvlan sin MAC extra
Alternativa a macvlan que no requiere modo promiscuo: los contenedores comparten la MAC del host y operan en capa 3.
Preguntas frecuentes
Q: ¿Cuándo merece la pena usar host networking en vez de bridge?
A: Host networking elimina la capa NAT y el contenedor comparte directamente la pila de red del host, lo que puede reducir latencia en aplicaciones muy sensibles a red. Pero solo funciona bien en Linux nativo: en Docker Desktop (Mac o Windows) hay una VM intermedia que lo neutraliza. Úsalo cuando necesites rendimiento máximo y estés seguro de correr en Linux bare-metal.
Q: ¿Por qué mis contenedores no se resuelven por nombre en la red por defecto?
A: La red bridge por defecto ('docker0') no incluye resolución DNS por nombre de contenedor. Esa funcionalidad solo está disponible en redes bridge definidas por el usuario, donde Docker levanta un servidor DNS interno en 127.0.0.11. Si necesitas que un contenedor encuentre a otro por nombre, crea tu propia red con 'docker network create'.
Q: ¿Qué pasa si mi router bloquea MACs desconocidas con macvlan?
A: macvlan asigna una MAC virtual al contenedor para que aparezca como dispositivo físico en tu red local, pero muchos routers domésticos y switches gestionados filtran tráfico de MACs no registradas o no permiten el modo promiscuo en la interfaz del host. Si ocurre esto, el contenedor quedará incomunicado aunque la configuración parezca correcta. ipvlan es una alternativa que evita ese problema al compartir la MAC del host.
Q: ¿Cómo accedo desde el host a contenedores en red macvlan?
A: Con macvlan el host no puede comunicarse directamente con los contenedores en esa red: es una limitación del driver. Para solucionarlo hay que crear una subinterfaz macvlan en el propio host y asignarle una IP dentro del mismo rango. Es un paso extra que muchos tutoriales omiten y que suele ser la fuente de confusión principal al arrancar con macvlan.
Q: ¿Vale bridge con puertos publicados para exponer servicios al exterior?
A: En la mayoría de casos domésticos y de homelab, sí: publicas el puerto con '-p 8080:80' y Docker gestiona el NAT automáticamente. La red bridge es el modo más portable y con mejor aislamiento por defecto. Las limitaciones aparecen cuando necesitas que el contenedor tenga IP propia en tu LAN (entonces macvlan o ipvlan) o cuando el overhead de NAT importa en producción intensiva (entonces host en Linux).
Deja una respuesta