app01 vive en un contenedor que sale a internet disfrazado de watchdogs — nunca aparece en el cable físico del instituto con su propia identidad, así que no necesitamos que nadie en soporte le abra nada.
Queríamos un contenedor LXC dedicado para app01, separado del hipervisor por seguridad — si algo dentro de Docker se porta mal, no toca a Proxmox ni a las demás VMs. El plan original era conectarlo directo al mismo cable que usa watchdogs (el bridge vmbr0), con IP por DHCP.
Al pedir IP por DHCP, el contenedor mandaba DHCPDISCOVER una y otra vez y no recibía ni una sola oferta. Silencio total — ni error, ni rechazo, nada.
La pista: el puerto de red del instituto donde está enchufado watchdogs solo tiene autorizada una MAC física (la que le dimos a soporte para moverte de VLAN). El contenedor nuevo generó su propia MAC virtual — distinta — y el switch, con port security activo, simplemente ignora cualquier tráfico que no venga de la MAC que ya conoce. Por eso ni siquiera llegaba a pedirle IP a nadie.
Había dos caminos. Pedirle a soporte que autorizara también la MAC del contenedor funciona, pero depende de ellos, hay que repetirlo cada vez que se crea algo nuevo, y les estás pidiendo que aflojen su control de acceso. La otra opción: que el contenedor nunca toque el cable físico — vive en una red que solo existe dentro de watchdogs, y sale a internet a través del host, usando la MAC que ya está autorizada.
Bridge directo a vmbr0 — el contenedor aparece en el cable del instituto con su propia MAC.
Resultado: 0 DHCPOFFERS — port security lo descartaBridge interno vmbr1 + NAT — el contenedor solo existe dentro del host; hacia afuera, todo sale con la MAC ya autorizada.
Resultado: invisible para el instituto, funciona sin pedir nadaAsí queda el camino completo, desde tu laptop hasta el contenedor. Dos fronteras distintas: Tailscale te lleva cifrado hasta watchdogs; de ahí, NAT te lleva del host hacia adentro, a una red que el instituto nunca ve.
Con el NAT ya configurado, seguía sin haber internet dentro del contenedor. La regla de MASQUERADE existía pero marcaba 0 paquetes — nunca la alcanzaba nada. La causa estaba un paso antes: la cadena FORWARD del firewall del host tenía política DROP por defecto, heredada de cuando instalamos Docker directo en watchdogs (Docker cambia esa política al instalarse, y solo abre paso a lo que él mismo administra).
El arreglo: dos reglas explícitas, una para dejar salir el tráfico de vmbr1 hacia vmbr0, y otra que solo deja regresar respuestas a conexiones ya iniciadas — no abre la red interna a que algo de afuera entre por su cuenta.
| Segmento | Rango | Quién vive ahí | Disponibles |
|---|---|---|---|
| Red del instituto | 192.168.50.0/24 | watchdogs · .151 | Compartida — no conectar nada nuevo aquí directo |
| Tailscale (overlay) | 100.64.0.0/10 | watchdogs · 100.104.16.118 tu laptop · 100.81.196.109 |
Cifrado, solo tus propios dispositivos |
| Red interna NAT | 10.10.10.0/24 | gateway · .1 app01 · .10 |
252 IPs libres para el próximo contenedor |
10.10.10.0/24 solo existe dentro de watchdogs — no hay ruta directa desde afuera. Por eso se entra saltando primero por el host:
Y para el próximo contenedor que necesite esta misma protección, la receta ya está probada: cuélgalo de vmbr1 en vez de vmbr0, dale una IP libre del rango 10.10.10.2–10.10.10.254, y ya sale a internet sin pedirle nada a nadie del instituto.
Soporte reasignó la IP de watchdogs en vmbr0: pasó de .210 a 192.168.50.151, y le dieron permiso especial a esa IP puntual en el firewall — en vez de moverte a una VLAN nueva, fue más simple para ellos autorizar la IP directo. Confirmado: el bloqueo que teníamos antes con los repositorios ya no aplica, tanto desde el host como desde cualquier contenedor detrás del NAT (todo sale disfrazado de esa misma IP).
Como el NAT de vmbr1 siempre sale por "lo que sea que tenga vmbr0 en ese momento", este cambio no rompió nada — se ajustó solo, sin tocar ni una regla.