En la lección 03-05 usaste las redes de Docker como una caja negra: creabas una red, conectabas contenedores y los nombres resolvían. Funcionaba, pero no sabías por qué. Esta lección abre esa caja: puentes de Linux, pares veth, reglas de iptables, un servidor DNS oculto en 127.0.0.11 y drivers que dan a un contenedor una IP propia en tu LAN física.

Todo lo que sigue se demuestra sobre la plataforma Aurora Libros en marcha. Los comandos del host asumen Linux; si usas Docker Desktop, se ejecutan dentro de la máquina virtual (lección 05-07).

1. Anatomía de una red bridge: puentes de Linux
2. Los pares veth y cómo emparejar los extremos
3. El camino de un paquete, paso a paso
4. iptables: las cadenas que crea Docker
5. NAT de salida y DNAT de publicación
6. El cortafuegos del host, saltado (aviso de seguridad)
7. DOCKER-USER: recuperar el control
8. El DNS embebido en 127.0.0.11
9. Direccionamiento: subredes, rangos, IP fija y MTU
10. Los drivers host y none en profundidad
11. macvlan: una IP propia en la LAN física
12. ipvlan en modo L2 y L3
13. Tabla comparativa de los seis drivers
14. IPv6 en Docker
15. Diagnóstico real: tcpdump y nsenter

Una red bridge de Docker es un puente de software del kernel de Linux: un conmutador Ethernet virtual. La red por defecto usa el puente docker0; cada red de usuario crea uno llamado br-<12 primeros caracteres del ID de red>.

La correspondencia es directa y comprobable: los doce caracteres tras br- son el principio del ID de la red. El puente tiene su propia dirección IP en el host, que es la puerta de enlace de los contenedores de esa red:

Y bridge link show master br-9f3a1c7d5e2b lista los interfaces enchufados a ese puente: uno por cada contenedor conectado a la red.

Un veth (virtual Ethernet) es un par de interfaces conectados por un cable virtual: lo que entra por un extremo sale por el otro. Docker crea uno por cada conexión contenedor-red: un extremo se queda en el host y se enchufa al puente; el otro se mueve dentro del contenedor y se renombra eth0. El emparejamiento no es evidente, porque los nombres son aleatorios; la clave está en el índice de interfaz, ya que cada extremo apunta al índice del otro mediante iflink.

Ya tienes el par: eth0 de aurora-api ↔ veth3a1f9c2 en el host. La notación @if6 del propio nombre confirma la simetría: el extremo del host apunta al índice 6, que es el eth0 del contenedor en su propio espacio de nombres de red.

Con el par identificado, puedes medir el tráfico de un contenedor concreto desde el host, sin entrar en él:

Fíjate en peer_ifindex: es la forma más directa de confirmar el emparejamiento. Y ojo con la inversión de sentido: lo que el contenedor envía es rx en el veth del host, porque el paquete entra al host por ese extremo.

Dos caminos muy distintos conviven aquí:

Que la comunicación aurora-api ↔ aurora-db sea pura conmutación explica por qué su rendimiento es prácticamente el de la red del host: no hay traducción de direcciones en ese camino.

Al arrancar, dockerd instala un conjunto de cadenas propias. Conocerlas por nombre te ahorra horas de depuración:

Ahí está, en dos líneas, el aislamiento que comprobaste en la lección 04-04 cuando aurora-web no podía llegar a aurora-db: un paquete que sale de un puente e intenta entrar en otro cae en el DROP.

Tres reglas, tres mecanismos:

• MASQUERADE de subred: todo lo que sale de 172.21.0.0/16 hacia fuera se reescribe con la IP del host. Es la razón de que un contenedor pueda descargar de Internet sin tener IP pública.
• DNAT de publicación: el -p 8080:80 de aurora-web se traduce en esta regla. Cualquier paquete que llegue al puerto 8080 de cualquier dirección local se redirige a 172.21.0.2:80.
• MASQUERADE con origen y destino iguales: el llamado hairpin NAT, que permite que un contenedor se alcance a sí mismo a través del puerto publicado del host.

Comprueba la correspondencia con la publicación real:

Si publicas restringiendo la interfaz —"127.0.0.1:8080:80"—, la regla cambia y añade -d 127.0.0.1. Esa diferencia de una palabra es la que separa "accesible desde mi portátil" de "accesible desde toda la red de la oficina".

Este es el punto más importante de la lección y el que más sorpresas desagradables causa en producción.

Cuando publicas un puerto, Docker inserta su DNAT en PREROUTING, que se evalúa antes que las reglas de la cadena INPUT donde ufw o firewalld ponen las suyas. El tráfico redirigido pasa por FORWARD, no por INPUT. Resultado: tu cortafuegos no ve ese tráfico y no lo bloquea.

El cortafuegos dice que solo el 22 está abierto. El puerto 5000 responde igualmente desde cualquier máquina de la red. Servidores enteros de PostgreSQL y Redis han acabado en Internet exactamente así.

Las tres defensas, de más simple a más completa:

Advertencia de seguridad. La exposición de puertos y las reglas de cortafuegos de un servidor deben revisarse con el responsable de seguridad o de compliance de tu organización. Lo que aquí se muestra explica el mecanismo; la política concreta —qué se expone, a quién y con qué controles compensatorios— no la decide quien escribe el compose.yaml en solitario.

Docker nunca toca DOCKER-USER y la evalúa antes que sus propias reglas. Es el lugar previsto para tus políticas:

Dos advertencias imprescindibles. La primera: el orden importa, -I inserta al principio, así que la regla permisiva debe insertarse en último lugar para acabar arriba. La segunda: estas reglas no sobreviven a un reinicio; hay que persistirlas con iptables-persistent, nftables o la herramienta de tu distribución. Y si piensas desactivar la manipulación de iptables por completo ("iptables": false en /etc/docker/daemon.json), asume que pierdes la salida a Internet de los contenedores y la publicación de puertos hasta que escribas tú todas las reglas: rara vez compensa.

En una red de usuario, los nombres de servicio resuelven porque Docker ejecuta un servidor DNS por contenedor escuchando en 127.0.0.11:53.

Esa dirección de loopback no existe en ninguna interfaz visible. El truco: dentro del espacio de nombres del contenedor hay una regla DNAT (-A DOCKER_OUTPUT -d 127.0.0.11/32 -p tcp --dport 53 -j DNAT --to-destination 127.0.0.11:38765) que redirige el tráfico a un puerto alto donde escucha un proceso del daemon.

El algoritmo de resolución, en orden:

1. ¿Es un nombre de servicio o alias de una red que compartimos? → responde el daemon con la IP del contenedor.
2. ¿Es un contenedor de la misma red por su nombre o container_name? → igual.
3. Si no, reenvía a los servidores DNS del host (o a los de dns: del servicio).

Puntos que conviene tener claros:

• La resolución está acotada a las redes compartidas. aurora-web no resuelve aurora-db porque no comparten red: no es un fallo de DNS, es el diseño.
• Con --scale, un mismo nombre devuelve varias direcciones en orden rotatorio: un balanceo rudimentario del lado del cliente. Compruébalo con docker compose up -d --scale aurora-api=3 seguido de getent hosts aurora-api.
• options ndots:0 evita que se añadan sufijos de búsqueda y ahorra consultas fallidas.
• Muchas librerías cachean la resolución. Si un contenedor se recrea y cambia de IP, una aplicación que resolvió una vez puede quedarse hablando con una IP muerta. Es un motivo real para reiniciar clientes tras recrear un servicio.

Por defecto Docker elige subredes de 172.17.0.0/16 en adelante, lo que choca con muchas VPN corporativas. Puedes fijarlas:

Asignar una IP fija exige que la red tenga subred propia: docker run -d --network aurora-fija --ip 10.80.0.10 nginx:alpine. En Compose se declara con ipv4_address dentro de networks. Aun así, la buena práctica sigue siendo depender de los nombres DNS y no de las IP: las IP fijas se reservan para casos donde algo externo (una regla de cortafuegos, una licencia, un equipo antiguo) exige una dirección estable.

El valor por defecto de la MTU se define en /etc/docker/daemon.json con "mtu": 1450. El síntoma típico de una MTU mal ajustada es cruel: las conexiones se establecen y las peticiones pequeñas funcionan, pero las respuestas grandes se quedan colgadas.

host elimina el espacio de nombres de red: el contenedor usa directamente la pila del host.

El proceso escucha directamente en el puerto 3000 del host. Lo que ganas y lo que pierdes:

Casos legítimos: agentes de monitorización (node-exporter, lección 05-06), balanceadores de muy alto rendimiento y herramientas de diagnóstico. Para aurora-api sería un error: perdería el aislamiento sin ganar nada apreciable.

none deja al contenedor únicamente con lo: docker run --rm --network none alpine:3 ping -c1 -W1 8.8.8.8 responde Network is unreachable. Es la opción correcta para procesos de cálculo puro o para tratar ficheros de origen dudoso: si no hay red, no hay exfiltración.

macvlan da al contenedor su propia dirección MAC en la red física. Para el resto de la oficina, el contenedor es un equipo más: obtiene una IP del rango real y no necesita NAT ni publicación de puertos.

Desde otro equipo de la oficina, http://192.168.1.241/ responde sin haber publicado ningún puerto.

Las tres trampas, en orden de frecuencia:

1. El host no puede hablar con sus propios contenedores macvlan. No es un fallo: el kernel impide el tráfico entre la interfaz padre y sus interfaces macvlan hijas. La solución es crear un interfaz macvlan adicional en el host y enrutar hacia él:

2. Modo promiscuo. El conmutador o el hipervisor deben aceptar varias MAC por puerto. En la mayoría de servicios de nube (y en muchas redes Wi-Fi) está prohibido, y macvlan sencillamente no funciona.
3. Colisión con el DHCP. Docker no habla DHCP: reserva un --ip-range fuera del ámbito del servidor DHCP o acabarás con dos equipos compartiendo IP.

ipvlan resuelve el problema del modo promiscuo: todos los contenedores comparten la MAC del interfaz padre y se distinguen por IP.

El modo L3 es el más limpio en centros de datos con enrutamiento controlado, pero exige que alguien enseñe al router cómo llegar a 10.90.1.0/24. Si no lo haces, los contenedores salen y nada vuelve.

El driver overlay, para comunicar contenedores de varios hosts, se cubre en la lección 06-03 junto con la malla de enrutamiento de Swarm.

Desde la versión 27, IPv6 se habilita por red sin tocar el daemon:

En Compose basta con enable_ipv6: true en la red. Tres avisos: usa direcciones ULA (fd00::/8) si no tienes un prefijo público delegado; activa "ip6tables": true en /etc/docker/daemon.json para que funcionen el NAT y la publicación; y comprueba que tus reglas de cortafuegos existen también en IPv6, porque una política solo IPv4 deja una puerta abierta que nadie mira.

La imagen nicolaka/netshoot con --network container: (lección 03-04) te pone dentro del espacio de nombres de red del contenedor con todas las herramientas:

Dos interfaces, porque aurora-api está en frontal y en trasera; la ruta por defecto sale por frontal, ya que trasera es internal y no tiene puerta de enlace.

Capturar el tráfico real entre la API y la base de datos:

Las direcciones son las de la red trasera y no hay ninguna traducción: comunicación directa a través del puente, tal como anticipaba el apartado 3. Desde el host, sin entrar en ningún contenedor, la captura equivalente es sudo tcpdump -n -i veth3a1f9c2 -c 5 'tcp port 5432'.

nsenter es la vía de más bajo nivel: entra en el espacio de nombres de red de un proceso usando las herramientas del host.

Es la técnica que salva el día cuando un contenedor es distroless y no tiene ni sh (lección 05-03): tú no necesitas nada dentro, porque usas los binarios del host sobre su namespace. El porqué exacto de que esto funcione está en la lección 05-07.

Creer que el cortafuegos del host protege los puertos publicados. No lo hace: el DNAT de Docker se evalúa antes. Publica en 127.0.0.1 o filtra en DOCKER-USER.

Añadir reglas en INPUT para bloquear un contenedor. El tráfico va por FORWARD. La cadena correcta es DOCKER-USER.

Escribir reglas dentro de la cadena DOCKER. Docker la reescribe al arrancar o al publicar un puerto, y tus reglas desaparecen.

Depender de las IP de los contenedores. Cambian al recrear. Usa nombres de servicio y reserva las IP fijas para requisitos externos reales.

Usar --network host para "que vaya más rápido". Pierdes el aislamiento y la resolución por nombre, y en una API HTTP la diferencia suele ser despreciable. Mide antes.

Montar macvlan sin comprobar el modo promiscuo, o olvidar bajar la MTU tras una VPN: en el primer caso todo parece bien configurado y nada responde; en el segundo, las conexiones se abren pero se cuelgan al transferir datos grandes.

Consejo: ante un problema de red, sigue siempre el mismo orden: ¿resuelve el nombre? (getent hosts), ¿hay ruta? (ip route), ¿escucha alguien? (ss -tlnp dentro del destino), ¿llega el paquete? (tcpdump). Cada paso descarta una capa entera.

Ejercicio 1. Con la plataforma levantada, identifica el par veth de aurora-db, demuestra que su extremo del host está enchufado al puente de la red trasera y mide el tráfico que ha pasado por él. Explica por qué rx en el host corresponde a lo que envía el contenedor.

Ejercicio 2. Demuestra el salto del cortafuegos: publica un contenedor en un puerto, comprueba que ufw no lo declara abierto y que aun así responde desde otra máquina; después bloquéalo correctamente con DOCKER-USER y verifica que sigue funcionando desde localhost.

Ejercicio 3. Captura con tcpdump una consulta real entre aurora-api y aurora-db provocada por curl /libros, y demuestra con docker exec sobre Redis por qué la segunda petición no genera tráfico hacia la base de datos.

Solución 1.

El master coincide exactamente con el puente derivado del ID de la red trasera: ese veth es el cable de aurora-db hacia esa red y no hacia otra. Y peer_ifindex: 10 apunta al índice del eth0 de dentro del contenedor.

Sobre la inversión de sentido: las estadísticas se leen desde el punto de vista del host. Cuando aurora-db responde a una consulta, el paquete sale por su eth0, viaja por el cable virtual y entra al host por veth5d80a3f; para el host eso es recepción, luego rx. Confundirlo lleva a diagnósticos invertidos: si ves rx disparado en el veth de una base de datos, no es que le estén enviando mucho, es que está devolviendo mucho, y probablemente falte un LIMIT en alguna consulta.

Solución 2.

La regla filtra por interfaz de entrada (-i eth0), así que el tráfico que llega por la interfaz física se descarta mientras que el que nace en el propio host —y por tanto no entra por eth0— sigue pasando. Ese matiz es lo que la hace utilizable: bloquea el exterior sin romper la depuración local.

La lección de fondo: ufw informaba de un sistema con un solo puerto abierto y era falso. Publicar un puerto en un servidor con IP pública equivale a abrirlo en Internet, salvo que ates la publicación a 127.0.0.1 o filtres explícitamente. Es exactamente el motivo por el que aurora-db no publica nada desde la lección 04-04.

Solución 3.

La primera petición devuelve origen: db y en la captura aparece el diálogo con PostgreSQL en el 5432, con direcciones de la red trasera sin traducir. La segunda devuelve origen: cache y no añade ni un paquete a la captura: el patrón cache-aside encuentra la clave libros:todos en Redis y ni siquiera abre una consulta.

Dos conclusiones útiles. La primera, de arquitectura: tcpdump acaba de convertir en observable algo que hasta ahora era un campo JSON en el que había que confiar. La segunda, de diagnóstico: si un día /libros respondiera origen: db siempre, esta misma captura te diría si el problema está en la escritura de la clave en Redis o en su lectura, sin tocar una línea de código.

Las redes de Docker han dejado de ser magia. Sabes que una red bridge es un puente de Linux —docker0 o br-<id>— con un extremo veth por contenedor enchufado a él, y sabes emparejar los extremos con iflink y ethtool -S para medir el tráfico de un contenedor concreto desde el host. Conoces los dos caminos de un paquete: conmutación pura entre contenedores de la misma red, y MASQUERADE cuando sale al exterior. Y has leído las reglas reales: la cadena DOCKER con su DNAT por cada -p, y DOCKER-ISOLATION-STAGE-2 con el DROP de dos líneas que explica todo el aislamiento entre redes que llevas usando desde el módulo 3.

Te llevas también un aviso que vale más que muchas configuraciones: publicar un puerto salta el cortafuegos del host, porque el DNAT se evalúa antes que INPUT; la defensa es publicar en 127.0.0.1, no publicar en absoluto o escribir reglas en DOCKER-USER, la única cadena que Docker respeta. Sabes cómo resuelve realmente un nombre el DNS embebido de 127.0.0.11 y por qué la resolución está acotada a las redes compartidas; controlas el direccionamiento (--subnet, --ip-range, --aux-address, mtu) para convivir con VPN y equipos reales; conoces en profundidad los seis drivers, incluidos macvlan con su trampa del modo promiscuo e ipvlan en L2 y L3; y diagnosticas con netshoot, ss, tcpdump sobre el tráfico real entre aurora-api y aurora-db, y nsenter cuando dentro del contenedor no hay ni un sh.

La siguiente capa que hay que abrir es la de los datos. En la lección 05-02 verás el almacenamiento a fondo: qué es un storage driver y cómo funciona overlay2 por dentro con sus lowerdir, upperdir y merged; cuánto cuesta realmente el copy-on-write —medido— y por qué eso obliga a que una base de datos use volúmenes; los volume drivers y sus opciones, incluidos NFS y los volúmenes compartidos entre pilas; y una estrategia de copias de seguridad de Aurora Libros con restauración probada, porque una copia que nunca se ha restaurado no es una copia.