Red Proxmox LXC rota: la lista de comprobación veth/tap que realmente encuentra la causa

Guía de diagnóstico rápido

Si estás de guardia, no necesitas una teoría. Necesitas un embudo. Este es el orden que suele encontrar el cuello de botella más rápido.

1) Decide: ¿es “solo el contenedor” o también el host?

• Si el host puede alcanzar el gateway e Internet pero el contenedor no: sospecha puente, firewall, VLAN, rp_filter, ruta del contenedor o MTU.
• Si el host tampoco puede: deja de tocar LXC. Arregla la red física upstream, rutas del host o firewall del host primero.

2) Confirma que el veth existe y está conectado al puente esperado

• Si no hay veth en el host: el contenedor no arrancó limpiamente, hay un error de configuración o la creación del veth falló por nombre/límites.
• Si el veth existe pero no está en vmbrX: nombre de puente equivocado en la configuración del contenedor, o se renombró un puente obsoleto.

3) Comprueba L2 primero, luego L3, luego la política

• L2: enlace arriba, pertenencia al puente, filtrado VLAN, aprendizaje/reenviamiento de MAC.
• L3: IP/máscara del contenedor, ruta por defecto, ARP/vecino, rutas del host.
• Política: firewall de Proxmox (datacenter/node/CT), nftables/iptables, sysctls (rp_filter, forwarding).

4) Usa un único “paquete conocido bueno”

• Desde el contenedor: haz ping al gateway IP, luego al IP del puente del host, luego a un IP externo.
• Si el ping al gateway falla, mira ARP/vecino y el puente/VLAN antes de perder tiempo en NAT/DNS.

5) Captura en ambos lados del veth

• Captura en el veth del host y en vmbrX. Si ves egress pero no ingress, el puente o las reglas VLAN están descartando.
• Si no ves nada en el veth del host, el contenedor nunca emitió el paquete (ruta, interfaz caída, política dentro del CT).

Una cita que deberías tener a mano cuando te tiente “simplemente reiniciarlo”: «La esperanza no es una estrategia.» — General Gordon R. Sullivan (citado a menudo en operaciones).

Modelo mental: veth, puentes y espacios de nombres (sin mitología)

En Proxmox LXC, el contenedor no recibe una “NIC real”. Recibe un extremo de un veth pair. El otro extremo está en el host y normalmente se enchufa en un puente Linux como vmbr0. Eso es todo. Ese es el truco.

Donde la gente se pierde es que la red abarca:

• El espacio de nombres de red del contenedor (sus propias interfaces, rutas, caché ARP).
• El límite del par veth (dos interfaces conectadas permanente punta a punta).
• El puente del host (comportamiento tipo switch: base de reenvío, filtrado VLAN, ajustes STP).
• La pila IP del host (si el host actúa como router/NAT, o si usas firewall en el host).
• El firewall de Proxmox (que no es magia; son reglas que terminan en netfilter).
• El switching upstream (trunk VLAN, límites de MAC, seguridad de puerto, MTU, peculiaridades de LACP).

Tap aparece mayormente con QEMU VMs, donde dispositivos tap conectan la VM al puente del host. LXC usa veth por defecto. Pero los patrones de fallo se solapan: puente equivocado, VLAN equivocada, caída por firewall, desajuste MTU, o “está arriba pero no reenvía”.

Aquí está la simplificación más útil:

• veth = un cable Ethernet virtual con dos extremos. Si un extremo está arriba, el otro aún puede estar abajo. Trátalo como un cable real.
• puente = un switch virtual. Si el filtrado VLAN está activado, puede comportarse como un switch gestionado y descartar silenciosamente.
• espacio de nombres = una habitación con su propia tabla de enrutamiento y caché ARP. No puedes depurar una habitación en la que nunca entras.

Broma #1 (corta, relevante): Un par veth es como un matrimonio: si un lado deja de hablar, el otro aún piensa que todo está “up”.

Hechos interesantes y contexto (porque tu yo futuro lo merece)

1. Los pares veth llegaron al kernel de Linux mucho antes de que los contenedores fueran mainstream. Empezaron como una forma genérica de conectar espacios de nombres y switches virtuales; Docker solo popularizó el patrón.
2. El puente de Linux precede a Open vSwitch en muchas implementaciones. Es antiguo, estable y muy capaz—especialmente desde que el filtrado VLAN y los ganchos de netfilter maduraron.
3. El firewall de Proxmox no es un dispositivo de firewall separado. Genera reglas de netfilter en el nodo. Si ejecutas tus propias reglas nftables, estás coescribiendo la política.
4. El descubrimiento ARP/vecino es la primera canaria. Si un contenedor no puede alcanzar su gateway, el 80% de las veces ARP falla por VLAN, puente o filtrado de MAC—no por “problemas de DNS”.
5. El filtrado por ruta inversa (rp_filter) se diseñó para anti-spoofing. Es genial hasta que haces enrutamiento asimétrico, policy routing o multi-homing. Entonces se convierte en un triturador silencioso de tráfico.
6. Los desajustes de MTU raramente rompen pings pequeños. Rompen cargas reales: handshakes TLS, descargas de imágenes de contenedores y cualquier cosa que desencadene fragmentación/fallos PMTUD.
7. El filtrado VLAN en un puente Linux es relativamente “nuevo” comparado con el bridging clásico. Muchos equipos lo activan por higiene y luego olvidan que el tráfico no etiquetado ahora necesita manejo de PVID explícito.
8. Las tablas de estado conntrack son un recurso finito. Cuando se desbordan o los timeouts son incorrectos, aparecen fallas de conectividad “aleatorias” en contenedores—especialmente bajo NAT.

Tareas prácticas: comandos, salidas, decisiones (la verdadera lista)

A continuación hay tareas prácticas. Cada una está diseñada para responder una única pregunta y forzar una siguiente acción. Ejecútalas en orden hasta encontrar la primera mentira.

Task 1 — Confirmar que el contenedor ve una interfaz y una IP

cr0x@server:~$ pct exec 101 -- ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             2a:7d:1c:4f:9b:12 <BROADCAST,MULTICAST,UP,LOWER_UP>

Qué significa: Si eth0 falta o está DOWN, para. Eso no es un problema de enrutamiento; es fontanería de la interfaz o configuración del contenedor.

Decisión: Si eth0 está abajo, inspecciona la configuración del contenedor y la creación del veth en el host (Tareas 5–7). Si está arriba, revisa IP/rutas a continuación.

cr0x@server:~$ pct exec 101 -- ip -br addr show dev eth0
eth0             UP             192.0.2.50/24 fe80::287d:1cff:fe4f:9b12/64

Decisión: ¿No hay dirección IPv4 cuando esperas una? Arregla DHCP/config estática dentro del CT (o la configuración de Proxmox si usas ip=dhcp).

Task 2 — Verificar la ruta por defecto dentro del contenedor

cr0x@server:~$ pct exec 101 -- ip route
default via 192.0.2.1 dev eth0
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.50

Qué significa: Si falta la ruta por defecto o apunta al gateway equivocado, el contenedor no puede salir de su subred.

Decisión: Arregla el gateway. No toques puentes/firewalls hasta que L3 dentro del CT sea sano.

Task 3 — Escalera de pings rápida (gateway → puente del host → IP pública)

cr0x@server:~$ pct exec 101 -- ping -c 2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.512 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.487 ms

--- 192.0.2.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Decisión: Si el ping al gateway falla, ve directo a ARP/vecino y a las comprobaciones de VLAN/puente (Tareas 4, 8, 10, 11). Si el ping al gateway funciona pero la IP pública falla, probablemente tienes enrutamiento/NAT/firewall upstream.

Task 4 — Comprobar el estado de vecino (ARP) dentro del contenedor

cr0x@server:~$ pct exec 101 -- ip neigh show dev eth0
192.0.2.1 lladdr 00:11:22:33:44:55 REACHABLE

Qué significa: REACHABLE/STALE está bien. INCOMPLETE significa que las solicitudes ARP no están siendo respondidas (desajuste VLAN, caída del puente, switch upstream o IP de gateway equivocada).

Decisión: Si ves INCOMPLETE, no ajustes DNS. Arregla la adyacencia L2/L3.

Task 5 — Encontrar el veth del lado host para el contenedor

cr0x@server:~$ pct config 101 | grep -E '^net'
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=2A:7D:1C:4F:9B:12,ip=192.0.2.50/24,gw=192.0.2.1,type=veth

Decisión: Confirma el nombre del puente. Si referencia vmbr1 pero esperas vmbr0, encontraste el error.

cr0x@server:~$ ip -br link | grep -E 'veth|vmbr0'
vmbr0            UP             3a:ad:be:ef:01:23 <BROADCAST,MULTICAST,UP,LOWER_UP>
veth101i0        UP             fe:9a:1c:0f:3b:7a <BROADCAST,MULTICAST,UP,LOWER_UP>

Qué significa: Proxmox normalmente nombra el veth del host como veth<ctid>i0. Si falta, la red del contenedor no se levantó.

Decisión: Si falta, mira los registros de arranque del contenedor y los mensajes del kernel (Tarea 14).

Task 6 — Confirmar que el veth está esclavizado al puente

cr0x@server:~$ ip link show master vmbr0
7: veth101i0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether fe:9a:1c:0f:3b:7a brd ff:ff:ff:ff:ff:ff

Decisión: Si el veth no aparece bajo vmbr0, el contenedor está conectado a ninguna parte. Arregla la asignación del puente o recrea la interfaz.

Task 7 — Comprobar estado del puerto del puente y las banderas de aprendizaje/flooding

cr0x@server:~$ bridge link show dev veth101i0
7: veth101i0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0 state forwarding priority 32 cost 2

Qué significa: Si el puerto está blocking o no forwarding, STP o una mala configuración del puente están deteniendo el tráfico.

Decisión: Si está bloqueado, inspecciona STP y la prevención de bucles en el puente y upstream (Tarea 12).

Task 8 — Verificar etiquetado/filtrado VLAN en el puente

cr0x@server:~$ bridge vlan show dev veth101i0
port              vlan-id  
veth101i0          1 PVID Egress Untagged

Qué significa: Con puentes conscientes de VLAN, el puerto necesita un PVID correcto para tráfico sin etiqueta, o membresía VLAN explícita para tráfico etiquetado.

Decisión: Si esperas VLAN 20 pero solo ves VLAN 1, o establece tag=20 en la configuración net del contenedor o ajusta las reglas VLAN del puente.

Task 9 — Confirmar que la configuración net del contenedor coincide con la intención VLAN

cr0x@server:~$ pct config 101 | grep -E '^net0'
net0: name=eth0,bridge=vmbr0,firewall=1,tag=20,hwaddr=2A:7D:1C:4F:9B:12,ip=192.0.2.50/24,gw=192.0.2.1,type=veth

Decisión: Si tu switchport es access VLAN 20 (sin etiquetar), no etiquetes dentro de Proxmox; usa sin etiqueta y configura el PVID del puente apropiadamente. Si el uplink del host es un trunk, etiquetar puede ser correcto. Alinea la realidad, no los deseos.

Task 10 — Comprobar la FDB del puente (aprendizaje de MAC)

cr0x@server:~$ bridge fdb show br vmbr0 | grep -i fe:9a:1c:0f:3b:7a
fe:9a:1c:0f:3b:7a dev veth101i0 master vmbr0 permanent

Qué significa: Si las MACs no se aprenden dinámicamente (o aparecen en el puerto incorrecto), puedes obtener rarezas como “funciona para un contenedor”.

Decisión: ¿No hay rastro de las MACs del contenedor? El tráfico puede no estar entrando al puente (el contenedor no emite, el firewall descarta o el veth está abajo).

Task 11 — Inspeccionar el estado del firewall de Proxmox en los tres niveles

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ cat /etc/pve/firewall/cluster.fw | sed -n '1,120p'
[OPTIONS]
enable: 1

[RULES]

cr0x@server:~$ cat /etc/pve/nodes/$(hostname)/host.fw | sed -n '1,160p'
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

Qué significa: Un DROP por defecto en el firewall del host puede romper el reenvío de contenedores si no permites explícitamente el tráfico del puente.

Decisión: Si no entiendes completamente tus políticas de firewall, desactiva temporalmente el firewall del CT para una prueba controlada, no como “solución”.

Task 12 — Comprobar si STP/ajustes del puente están impidiendo silenciosamente el reenvío

cr0x@server:~$ cat /etc/network/interfaces | sed -n '1,220p'
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.0.2.10/24
        gateway 192.0.2.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

Decisión: Si STP está activo y no lo esperas, puedes estar esperando retrasos de forwarding o golpeando un puerto bloqueado. Si bridge-vlan-aware está activado, debes gestionar la membresía VLAN intencionalmente.

Task 13 — Validar sysctls del host que afectan el reenvío y la asimetría

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter net.ipv4.conf.vmbr0.rp_filter
net.ipv4.ip_forward = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.vmbr0.rp_filter = 1

Qué significa: Si haces routing/NAT en el host y tienes caminos asimétricos (múltiples uplinks, policy routing, VRFs), rp_filter=1 puede descartar tráfico válido.

Decisión: Si sospechas de rp_filter, prueba con rp_filter=2 (loose) en interfaces relevantes, luego asegúralo con enrutamiento correcto. No lo dejes en “lo que sea que haga que funcione” sin entenderlo.

Task 14 — Buscar pistas del kernel: veth, bridge, nf_tables, MTU

cr0x@server:~$ dmesg -T | tail -n 30
[Thu Dec 26 09:14:02 2025] device veth101i0 entered promiscuous mode
[Thu Dec 26 09:14:02 2025] vmbr0: port 7(veth101i0) entered blocking state
[Thu Dec 26 09:14:03 2025] vmbr0: port 7(veth101i0) entered forwarding state

Decisión: Si ves errores como “failed to create veth”, “RTNETLINK answers: File exists”, o advertencias relacionadas con MTU, tienes un problema a nivel de host: colisiones de nombres, agotamiento de recursos o secuencia de configuración mala.

Task 15 — Rastrear paquetes con tcpdump en ambos lados

cr0x@server:~$ tcpdump -ni veth101i0 arp or icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on veth101i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:18:10.102938 ARP, Request who-has 192.0.2.1 tell 192.0.2.50, length 28

Decisión: Si las solicitudes ARP salen del veth pero nunca ves respuestas, comprueba VLAN y el switch upstream. Si ves respuestas en vmbr0 pero no en veth101i0, algo en el host está filtrando entre el puente y el puerto (filtrado VLAN del puente, reglas ebtables/nft del puente, firewall de Proxmox).

cr0x@server:~$ tcpdump -ni vmbr0 arp or icmp
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:18:10.102944 ARP, Request who-has 192.0.2.1 tell 192.0.2.50, length 28

Decisión: Ver la misma solicitud en vmbr0 es bueno: el paquete está entrando en el dominio del puente. Ahora encuentra dónde muere la respuesta.

Task 16 — Verificar que nftables/iptables no esté matando el tráfico del puente

cr0x@server:~$ nft list ruleset | sed -n '1,200p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
}

Qué significa: Un DROP por defecto en forward romperá el tráfico de contenedores enrutado/NATeado. El tráfico bridged también puede verse afectado dependiendo de sysctls y ajustes bridge netfilter.

Decisión: Si dependes de routing/NAT en el host, añade aceptaciones explícitas en forward para la subred del contenedor y la interfaz de salida. Si estás haciendo solo bridging, inspecciona bridge-nf-call-iptables (Tarea 17).

Task 17 — Comprobar sysctls de bridge netfilter (el multiplicador silencioso de políticas)

cr0x@server:~$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.bridge.bridge-nf-call-arptables
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-arptables = 0

Qué significa: Cuando están habilitados, los paquetes bridged pueden atravesar los ganchos de iptables/nft. Eso puede ser bueno (seguridad) o desastroso (descartes por sorpresa).

Decisión: Si no tenías la intención de filtrar tráfico bridged, pon estos a 0 y confía en límites L2/L3 adecuados—o escribe reglas conscientemente.

Task 18 — Validar MTU entre contenedor, veth, puente y uplink

cr0x@server:~$ ip -br link show dev veth101i0 vmbr0 eno1
veth101i0         UP             fe:9a:1c:0f:3b:7a <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
vmbr0             UP             3a:ad:be:ef:01:23 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
eno1              UP             58:11:22:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000

Qué significa: Un uplink a 9000 y un puente a 1500 no siempre es incorrecto, pero es un terreno fértil para casos borde de PMTUD si hay enrutamiento/NAT implicado.

Decisión: Estandariza MTU de extremo a extremo para el segmento, o demuestra con capturas que la fragmentación/ICMP “frag needed” funciona.

Task 19 — Confirmar que el DNS del contenedor no sea el chivo expiatorio

cr0x@server:~$ pct exec 101 -- getent hosts example.com
2606:2800:220:1:248:1893:25c8:1946 example.com
93.184.216.34 example.com

Decisión: Si el ping al gateway funciona pero DNS falla, arregla los resolutores (el /etc/resolv.conf dentro del CT o el manejo por systemd-resolved). No reescribas configuraciones de puente por un tema de DNS.

Task 20 — Probar conectividad host→contenedor (sanidad local)

cr0x@server:~$ ping -c 2 192.0.2.50
PING 192.0.2.50 (192.0.2.50) 56(84) bytes of data.
64 bytes from 192.0.2.50: icmp_seq=1 ttl=64 time=0.221 ms
64 bytes from 192.0.2.50: icmp_seq=2 ttl=64 time=0.213 ms

--- 192.0.2.50 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Decisión: Si el host no puede hacer ping al contenedor pero el contenedor puede hacer ping al puente del host, sospecha política de firewall en el host o filtrado ebtables/nft del puente.

Errores comunes: síntoma → causa raíz → solución

1) “El contenedor tiene IP pero no puede hacer ping al gateway”

Causa raíz: Desajuste VLAN o puente con conciencia de VLAN descartando tramas sin etiquetar; a veces el switch upstream es access VLAN X pero Proxmox etiqueta VLAN X (doble etiquetado o etiquetado incorrecto).

Solución: Haz explícita la intención VLAN. Si el uplink es trunk y el contenedor debe estar en VLAN 20, establece tag=20 y asegúrate de que vmbr0 permita VLAN 20. Si el uplink es access VLAN 20, no etiquetes en Proxmox; asegúrate de que el PVID del puerto coincida.

2) “Funciona durante minutos y luego muere; reiniciar el contenedor lo arregla”

Causa raíz: Renovación de tablas Neighbor/ARP por IP duplicada, MAC duplicada (CT clonado), o límite/mac-security upstream que impide el aprendizaje.

Solución: Asegura MAC única por CT; nunca clones y lo olvides. Comprueba la seguridad de MAC en el switch upstream. Verifica que no haya IPs duplicadas en el segmento.

3) “El contenedor puede hacer ping a IPs pero no resolver nombres”

Causa raíz: Mala configuración DNS, problemas con systemd-resolved, o Proxmox inyectando resolutores equivocados. A veces el firewall bloquea UDP/53 mientras ICMP pasa.

Solución: Valida /etc/resolv.conf dentro del CT y ejecuta getent hosts. Si el firewall está activo, permite DNS explícitamente.

4) “Solo fallan descargas grandes; los pings funcionan”

Causa raíz: Desajuste MTU + PMTUD roto (ICMP “frag needed” bloqueado), o redes overlay interactuando con jumbo frames.

Solución: Estandariza MTU; permite ICMP tipo 3 código 4 donde corresponda; confirma con tcpdump y una prueba grande con curl o ping -M do -s.

5) “El tráfico funciona hasta que activamos el firewall de Proxmox”

Causa raíz: DROP por defecto en políticas node/host/CT con reglas de allow faltantes para el reenvío del puente; o sysctls de bridge netfilter haciendo que paquetes bridged pasen por reglas L3 inesperadamente.

Solución: Audita políticas en datacenter/node/CT. Decide dónde debe ocurrir el filtrado. Mantén los sysctls de bridge-nf intencionales.

6) “El contenedor puede alcanzar el host pero nada más; se supone que hay NAT”

Causa raíz: net.ipv4.ip_forward del host está desactivado, la cadena forward descarta, o las reglas NAT están en iptables mientras el sistema usa nftables (o viceversa).

Solución: Valida el sysctl de forwarding, asegura que la cadena forward acepte, y verifica que estés escribiendo reglas en el backend de firewall activo.

7) “Después de migrar un CT a otro nodo, la red se rompió”

Causa raíz: Deriva de configuración del nodo: nombres de vmbr distintos, ajustes VLAN-aware, MTU o valores por defecto de firewall.

Solución: Trata la red del nodo como un contrato API. Estandariza /etc/network/interfaces entre nodos y verifica con una checklist previa a la migración.

Broma #2 (corta, relevante): Los errores VLAN son como el purpurina—cuando aparecen, los encuentras en sitios que no tocaste.

Listas / plan paso a paso

Checklist A — “El contenedor no puede alcanzar el gateway” (el más común)

1. Dentro del CT: ip -br addr y ip route. Arregla IP/ruta faltante primero.
2. Dentro del CT: ip neigh. Si el gateway está INCOMPLETE, es L2/VLAN/puente.
3. En el host: confirma que el veth existe y está en el puente esperado (ip -br link, ip link show master vmbr0).
4. En el host: comprueba membresía VLAN (bridge vlan show). Compáralo con el modo del switchport (access vs trunk) y el tag= en Proxmox.
5. Captura ARP en veth del host y en vmbr. Si la request sale pero la respuesta no vuelve, ve upstream (config del switch, seguridad MAC, cableado, problemas de hashing LACP).

Checklist B — “El gateway funciona, Internet no”

1. Haz ping a una IP pública (no un nombre). Si falla, es enrutamiento/NAT/firewall, no DNS.
2. Confirma que el host tiene conectividad y ruta por defecto correcta.
3. Si usas routing/NAT en el host: verifica net.ipv4.ip_forward=1, política de forward y reglas NAT aplicadas en el backend de firewall activo.
4. Comprueba rp_filter si existen múltiples caminos.
5. Sólo después de que la conectividad IP funcione: valida DNS.

Checklist C — “Intermitente o relacionado con rendimiento”

1. Comprueba MTU en uplink, puente, veth y contenedor.
2. Comprueba presión en la tabla conntrack (síntomas: caídas aleatorias bajo carga).
3. Captura y busca retransmisiones, ICMP frag-needed o anomalías en TCP MSS.
4. Audita reglas de firewall por timeouts de seguimiento stateful y descartes inesperados.

Tres mini-historias del mundo corporativo (para que no las repitas)

Historia 1 — El incidente causado por una suposición equivocada

Tuvieron un plan “simple”: mover un conjunto de servicios legacy de VMs a LXC para ahorrar memoria. La red era “la misma”, porque todo seguía en vmbr0. Esa frase es cómo empiezan los incidentes.

El primer contenedor arrancó con IP y respondió pings desde el host. ¿Desde la red externa? Muerto. El equipo supuso que el firewall upstream no aceptaba la nueva MAC, así que abrieron tickets y esperaron. Mientras tanto, los servicios estaban abajo y el canal de incidentes hacía lo que hacen los canales de incidentes: generar calor, no datos.

El problema real era un desajuste VLAN introducido por una suposición “obvia”: el switchport era un puerto access para VLAN 30, así que pusieron tag=30 en el contenedor. En ese puerto, las tramas ya eran sin etiqueta VLAN 30. El contenedor efectivamente enviaba tramas VLAN 30 etiquetadas a un puerto access que las descartaba. ARP nunca completó. Sin gateway, sin alegría.

Lo que lo empeoró: el host mismo tenía una IP en esa VLAN access y podía alcanzar el gateway, así que “el host funciona” se usó como prueba de que el contenedor debería funcionar. Pero el host estaba sin etiquetar; el contenedor etiquetado. Realidades diferentes, mismo cable.

La solución fue aburrida: quitar la etiqueta, mantener el contenedor sin etiqueta y documentar el modo del switchport en el estándar de red del clúster. Después añadieron una prueba previa al vuelo: ejecutar bridge vlan show y compararlo con la configuración del switchport antes de la migración.

Historia 2 — La optimización que salió mal

Otra organización estaba orgullosa de su postura de seguridad. Activaron el firewall de Proxmox en todas partes, pusieron políticas por defecto a DROP y lo desplegaron en una ventana de cambios que parecía generosa en el calendario. No lo fue en la operación real.

Las fallas de conectividad no eran totales. Algunos contenedores podían hablar con su base de datos; otros no. DNS a veces funcionaba. ICMP fue inconsistente. Ese es el tipo de fallo que hace dudar de la física.

La “optimización” fue activar los ganchos de bridge netfilter porque querían filtrar tráfico “aunque esté bridged”. Activaron net.bridge.bridge-nf-call-iptables=1 y aplicaron un conjunto de reglas L3 que asumían tráfico enrutado. De repente, las tramas bridged estaban sujetas a una política de forward DROP. Ciertos flujos sobrevivían por tracking de estado; otros no. Parecía aleatorio porque era política stateful encontrándose con una topología para la que no fue diseñada.

El camino más rápido para salir fue decidir: filtrar en límites L3 enrutados, o filtrar en L2/puente intencionalmente, pero no por accidente. Desactivaron bridge netfilter en nodos donde el diseño era puro bridging, mantuvieron el firewall de Proxmox para interfaces de gestión y movieron controles east-west a un lugar que realmente entendiera el modelo de tráfico.

Tras el incidente, el mejor cambio no fue técnico. Fue procedimental: cualquier cambio de firewall requería que un contenedor “conocido bueno” ejecutara un conjunto fijo de pruebas (ping al gateway, resolver DNS, conectar TCP) antes de ampliar el despliegue.

Historia 3 — La práctica aburrida pero correcta que salvó el día

Una empresa relacionada con finanzas (esas que tratan el downtime como un evento de carrera) tenía un estándar de clúster que molestaba a los ingenieros: cada nodo tenía nombres de puente idénticos, ajustes VLAN-aware y MTUs iguales. Sin excepciones. Si un nodo necesitaba manejo especial, tenía su propio clúster.

Durante una renovación de hardware, migraron contenedores nodo a nodo todo el día. Una migración falló: un contenedor perdió conectividad externa inmediatamente después de arrancar en el nodo nuevo. El ingeniero on-call no especuló. Ejecutó la checklist estándar: confirmar que el veth existe, comprobar membresía del puente, comprobar membresía VLAN, tcpdump ARP en ambos lados.

En minutos vieron solicitudes ARP saliendo del veth pero nunca apareciendo en el uplink físico. Eso lo redujo a fontanería puente/uplink, no al contenedor. Después, ip link show master vmbr0 reveló que el veth estaba en vmbr0, pero vmbr0 no estaba en la NIC que pensaban. El nombre de la interfaz había cambiado por actualizaciones de firmware/BIOS y el predictable network interface naming haciendo lo que prometió: ser predecible, solo que no de la forma que esperaban.

Como tenían gestión de configuración, redeployaron la configuración de red del nodo con el nombre de NIC corregido y listo. Sin depuración única, sin “quizás reiniciar”. La práctica que los salvó fue aburrida: imponer estandarización y tratar la configuración de red del nodo como código de producción.

Preguntas frecuentes

1) ¿Proxmox LXC usa dispositivos tap o veth?

Normalmente veth para LXC. Tap es común para VMs QEMU. La superposición en la resolución de problemas está en la pertenencia al puente, VLAN, firewall y MTU.

2) ¿Cómo encuentro qué veth pertenece a qué contenedor?

Empieza con pct config <ctid> para MAC/puente. Luego lista ip -br link | grep veth. Los nombres suelen verse como veth<ctid>i0.

3) Mi contenedor puede hacer ping al host pero no al gateway. ¿Qué implica?

Probablemente tienes conectividad local al puente pero falta adyacencia L2/L3 upstream: desajuste VLAN, seguridad de puerto del switch upstream o etiquetado/PVID incorrecto.

4) ¿Activar el firewall de Proxmox bloquea automáticamente contenedores?

PUEDE hacerlo, dependiendo de políticas por defecto y conjuntos de reglas en niveles datacenter/node/CT. También vigila los sysctls de bridge netfilter; pueden hacer que el tráfico bridged caiga en reglas L3 inesperadamente.

5) ¿Cuál es la forma más rápida de demostrar que es un tema VLAN?

Comprueba bridge vlan show dev vethXYZ y compáralo con el tag= del contenedor y el modo del switchport upstream. Luego captura ARP en vmbr y en el uplink.

6) ¿Por qué los pings funcionan pero HTTPS falla?

Clásico fallo MTU/PMTUD o problemas de TCP MSS. ICMP echo es pequeño; los handshakes TLS y la transferencia de datos no lo son. Verifica MTU y busca comportamiento ICMP “frag needed”.

7) ¿Cuándo debo sospechar de rp_filter?

Cuando tienes múltiples uplinks, policy routing, VRFs o caminos de retorno asimétricos. Si el tráfico desaparece sin un descarte claro del firewall, rp_filter es un sospechoso principal.

8) ¿Puedo “arreglar” esto cambiando de bridging a enrutamiento/NAT?

Puedes, pero eso no es una solución; es un cambio de diseño. Si enrutas/NATeas, debes controlar sysctls de forwarding, la política de la cadena forward y las reglas NAT. Hazlo intencionalmente.

9) Mis contenedores pierden red después de migración en caliente o restauración. ¿Por qué?

Deriva en la configuración del nodo: nombres de puente distintos, ajustes VLAN-aware, valores por defecto de firewall o MTU. Estandariza la red del nodo y valida antes de migraciones.

Próximos pasos (qué cambiar después de arreglarlo)

Una vez que hayas encontrado la causa, no te quedes en “ya funciona”. Los sistemas de producción regresan porque la ambigüedad subyacente permanece.

1. Estandariza la red de los nodos. Mismos nombres de vmbr, misma opción VLAN-aware, mismo MTU. Trátalo como un contrato API para las cargas de trabajo.
2. Documenta la intención VLAN en un solo lugar. Para cada puente/uplink: trunk vs access, VLANs permitidas y si los contenedores deben etiquetar.
3. Haz el firewall deliberado. Decide si filtras tráfico bridged. Si sí, escribe reglas con ese topology en mente. Si no, desactiva los ganchos bridge netfilter.
4. Mantén un contenedor conocido bueno. Un CT pequeño que pueda hacer ping al gateway, resolver DNS y alcanzar un endpoint TCP. Ejecútalo tras cualquier cambio de red/firewall.
5. Cultura de captura primero. Cuando dudes, tcpdump en ambos lados del veth y en el puente. Si no puedes ver el paquete, estás discutiendo con un fantasma.