La teoría define qué debe ocurrir. Las figuras y tablas reducen el mecanismo a señales observables; la topología y el inspector de paquete permiten comprobarlo después. Cada lección termina con «Lo entiendo»: márcala cuando puedas explicarla, no cuando la hayas leído.
Conceptos disponibles18
El incidente que este módulo te ayuda a desenredar
En el módulo 1 ya viste un salir del cliente y quizá desaparecer. Ahora la pregunta es: ¿qué parte del host Linux decidió su camino? En un host con contenedores no hay una sola “red”: hay namespaces, cables virtuales, bridges, rutas, traducciones y reglas que pueden afectar el mismo flujo en instantes distintos. [1]
El objetivo no es aprender comandos ip o iptables de memoria. Es poder explicar, por ejemplo: “el paquete salió del namespace worker, cruzó su veth, fue enrutado por el host y la cadena FORWARD lo descartó antes del namespace api”.
Mapa mínimo: del proceso aislado a la decisión de firewall
Flujo del mecanismo4 etapas
Del contenedor al firewall del host
No hay una sola red: cada borde tiene una responsabilidad distinta.
aislamiento
namespace. Aísla interfaces, rutas, puertos y sockets del workload.
Ver la figura original
proceso en contenedor
│
▼
network namespace ── tiene sus propios puertos, rutas e interfaces
│
▼
veth ── cable virtual; un extremo recibe lo que el otro transmite
│
▼
bridge o ruta L3 ── decide por MAC o por prefijo IP
│
▼
Netfilter/conntrack ── permite, deniega o traduce el flujo
La distinción importante es esta: un bridge no decide por IP ni “pasa por FORWARD” necesariamente; una L3 sí lleva el paquete a Netfilter. Por eso primero identificas el camino y sólo después interpretas una regla. [2]
Ruta de estudio y conexión con el roadmap
Construye dos namespaces y mira qué objetos pertenecen a cada uno.
Sigue un paquete por veth y bridge para distinguir L2 de routing L3.
Usa PREROUTING, FORWARD y POSTROUTING para ubicar una regla.
Añade /NAT para explicar el estado y la pérdida de identidad por IP.
El siguiente módulo añade una pregunta distinta: aun cuando el paquete llega al destino, ¿cómo sabe la aplicación qué nombre e identidad criptográfica está al otro lado? Ahí entran , y .
El aislamiento aparece antes de que exista un contenedor
Un contenedor recibe un network namespace y objetos kernel. Al crearlo sólo existe lo. o Docker crea un veth, mueve un extremo, asigna dirección y añade rutas. Host conserva el peer y lo conecta a bridge, VRF o ruta L3. Por eso una captura en eth0 no ve tráfico que nunca salió del bridge. [1]
Flujo del mecanismo5 etapas
El paquete cruza dos namespaces a través del host
api y worker no comparten red: el host une sus bridges y decide en FORWARD.
origen
netns api. El proceso envía por eth0 (172.30.10.2/24), la interfaz dentro de su namespace.
Bridge decide por MAC y router por prefijo. Si dos workloads viven en mismo bridge/, un frame puede cruzar L2 sin tocar FORWARD: separe dominios o aplique enforcement bridge/CNI. [2]
Netfilter y conntrack: primer paquete frente a flujo
Conntrack fija tupla original/reply al primer paquete. NAT se fija entonces y los posteriores reutilizan estado. DNAT puede transformar destino público 203.0.113.10:443 a backend 172.30.10.2:8443 antes de FORWARD, mientras conntrack conserva ambos. Filtrar sin decir pre/post NAT produce reglas aparentemente correctas que no protegen backend esperado. [2]
Fase
Valor relevante
Pregunta de auditoría
PREROUTING nat
destino público
¿a qué backend se tradujo?
FORWARD filter
destino tras DNAT
¿backend permitido correcto?
POSTROUTING nat
origen tras SNAT
¿qué identidad pierde receptor?
conntrack
original/reply tuple
¿retorno pertenece a flujo aprobado?
Pulsa una fila para fijarla.
MASQUERADE resuelve egress con IP variable, pero borra origen para receptor y abre estado por conexión. Dimensionar conntrack, registrar drops y retener identidad del workload son controles operativos. [2]
Lectura de una denegación sin adivinar
LN2-FORWARD recibe sólo worker→api: permite retorno establecido, /8080 y termina en . El DROP no protege host entero; protege el flujo en scope. Esta precisión evita que un lab se convierta en un cambio peligroso de firewall global. [2]
Figura
pkts bytes target prot source destination
1 60 ACCEPT all 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
1 60 ACCEPT tcp 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
1 60 DROP all 0.0.0.0/0 0.0.0.0/0
Si el contador DROP sube al probar 8081 hay enforcement. Si no cambia, investigue ruta/bridge/cadena antes de culpar la regla.
Referencia técnica: primitivas y datapath
Cada netns tiene interfaces, rutas, puertos, sockets y Netfilter propios. Veth es par: TX en uno es RX en peer. Bridge aprende MAC origen en FDB, entrega por puerto conocido o inunda unknown/broadcast; es L2 y no implementa autorización L3. [1]
Datapath : NIC→PREROUTING→ruta→INPUT para local, o FORWARD→POSTROUTING para tránsito. Paquete local: OUTPUT→POSTROUTING. Conntrack asocia tupla inicial/reply; nat crea traducción por flujo; filter acepta/deniega; mangle marca. MASQUERADE es SNAT dinámico: útil para egress variable, costoso en atribución/estado. [2]
Primitiva
Invariante
Riesgo cloud-native
netns
puertos/rutas aislados
asumir host y pod comparten listener
veth
frontera por workload
capturar interfaz equivocada
bridge
forwarding MAC
lateral movement L2
conntrack
estado/timeout
agotamiento DoS
SNAT
origen reescrito
logs sin IP cliente
Pulsa una fila para fijarla.
DNAT en PREROUTING modifica destino antes de FORWARD; documente pre/post NAT. DROP expira; REJECT expone decisión. Default allow FORWARD abre red lateral.
Referencia: no cuenta para tu progreso. Vuelve aquí cuando necesites un campo o un estado concreto.
Checkpoint 02 · predice antes de revelar
Un bridge no convierte FORWARD en una política L2
Dos namespaces están conectados a puertos distintos del mismo Linux bridge y comparten subred. La FDB ya conoce la MAC del destino. Una política IP en FORWARD del host dice DROP, pero el tráfico entre ambos sigue llegando.
br-ln2-api: FDB aa:bb:cc:dd:ee:02 dev veth-api
worker → bridge: dst aa:bb:cc:dd:ee:02, ethertype IPv4
api recibe el frame; contador de la cadena FORWARD no aumenta
Inspector de paquete
worker veth → worker bridge → host route/FORWARD → api bridge → api veth
172.30.20.2:49152 → 172.30.10.2:8080
081624
IPv4TCP
IPv4 · bits 64–71 · 8 bits
TTL
64
Saltos restantes. Cada router lo decrementa; en 0 descarta y emite ICMP Time Exceeded.
Cambia en cada salto: por eso el checksum IP se recalcula en cada router.
40 bytes · hex
0000
0008
0010
0018
0020
Supuestos de la síntesis
Puerto origen 49152: primer puerto efímero IANA, ilustrativo.
TTL inicial 64 (valor por defecto de Linux); Identification 0x1c46 ilustrativo.
SYN sin opciones TCP para que la cabecera quepa en 20 bytes; un SYN real de Linux añade MSS, SACK, timestamps y window scale. ISN ilustrativo.
Comprueba que la salida contiene «--dport 8080 -j ACCEPT».
¿Vas a practicar en Linux? Verifica tu entornoOpcional
Usa esta ruta sólo después de preparar el laboratorio en tu propia máquina. No hace falta instalar ni ejecutar nada para leer, explorar o completar los checkpoints.
pnpm verifier:build
sudo ./bin/lnverify run lab-02-netns-netfilter --json
Carga tu verificación
Ejecuta el script instrumentado. Evalúa cada check por separado y escribe una línea ::lnet por check, en vez de abortar en el primero.
O usa el verificador en Go, que produce los mismos marcadores o JSON:
sudo ./bin/lnverify run lab-02-netns-netfilter
Pega la salida aquí. También vale la salida del script original (PASS-lab-02) o una traza de bash -x.