Redes en Proxmox VE explicadas: bridges, bonds y VLAN

Primero la respuesta: el único modelo mental

La red de Proxmox VE es red de Linux, organizada alrededor de una idea: las máquinas virtuales y los contenedores conectan sus tarjetas de red virtuales a switches por software llamados bridges de Linux. El bridge predeterminado, vmbr0, se crea durante la instalación con tu tarjeta de red física conectada; esa es la única razón por la que tu primera VM pudo llegar a internet.

Cada configuración real es una variación de dónde se conectan esos bridges:

• Bridged: la VM está directamente en la red física con su propia IP pública y su propia MAC. La más simple, pero en un proveedor de hosting requiere IP/MAC adicionales autorizadas por el proveedor.
• Routed: el host posee las direcciones públicas y enruta el tráfico hacia las VM. Funciona en cualquier sitio, sin restricciones de MAC, algo más de configuración.
• NAT / privado: las VM viven en un bridge privado y comparten la IP del host para el tráfico saliente. Adecuado para VM que no necesitan ser accesibles públicamente.

La configuración vive en un único archivo legible, /etc/network/interfaces, y como Proxmox usa ifupdown2, los cambios se aplican en caliente con ifreload -a (o el botón "Apply Configuration" de la interfaz), sin reinicios. Este artículo asume una instalación funcionando; si aún no llegaste ahí, empieza por nuestra guía de instalación de Proxmox VE, que presenta vmbr0 brevemente; esta es la profundización prometida. Las direcciones de abajo son rangos de documentación (203.0.113.0/24, 10.0.0.0/24); sustitúyelas por las tuyas.

Anatomía de vmbr0

En una instalación recién hecha, /etc/network/interfaces se reduce a esto:

auto lo
iface lo inet loopback

iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0

Léelo de abajo hacia arriba y el modelo encaja: la tarjeta de red física (enp1s0) no lleva ninguna IP propia; es puramente un puerto del bridge. El bridge posee la dirección IP del host y el uplink. Las VM conectan sus tarjetas de red virtuales (dispositivos tap) a ese mismo bridge, con lo que este se convierte en un switch no gestionado con la tarjeta de red física como puerto de uplink. Todo lo demás en este artículo consiste en añadir más bridges, etiquetar tráfico en ellos, o cambiar lo que los alimenta.

Los tres patrones en un servidor alojado

En tu propio switch de casa, la red bridged simplemente funciona. En un servidor dedicado de un proveedor hay una restricción que respetar: los switches de acceso del datacenter suelen aplicar filtrado de MAC; el tráfico de direcciones MAC que el proveedor no espera en tu puerto se descarta. Ese único hecho determina qué patrón encaja:

Bridged: VM con su propia IP pública

Cada VM recibe una IP pública y su MAC virtual aparece en el switch del proveedor. Esto requiere IP adicionales asignadas a tu servidor por el proveedor, con la MAC de la VM registrada donde el proveedor lo exija (algunos asignan una MAC por IP; algunos aceptan cualquier MAC en tu puerto para subredes routed). Cuando esto es compatible (como en nuestra red, donde el espacio de IP adicional viene con el servidor), es la configuración más limpia: la configuración de la VM se reduce a "conectar a vmbr0, fijar la IP asignada y la misma puerta de enlace que el host".

Routed: funciona bajo cualquier política de MAC

En el cable solo aparece siempre la MAC del host; el host enruta por sus VM. Un esquema: subred pública 203.0.113.64/26 enrutada hacia tu servidor:

auto vmbr1
iface vmbr1 inet static
    address 203.0.113.65/26
    bridge-ports none
    bridge-stp off
    bridge-fd 0

bridge-ports none es el truco que vale la pena interiorizar: un bridge sin puerto físico es un switch puramente interno. Las VM en vmbr1 usan 203.0.113.65 como puerta de enlace; el host hace forwarding entre vmbr1 y el uplink (activa net.ipv4.ip_forward en /etc/sysctl.d/). El switch del proveedor nunca ve nada más que el host.

NAT: VM privadas que pueden salir

El mismo bridge sin puerto con un rango privado (10.0.0.1/24 en el bridge), más una regla de masquerade para que las VM compartan la IP pública del host en el tráfico saliente. Adecuado para VM de build, bases de datos que solo sirven a otras VM, e invitados de laboratorio. El acceso entrante, si hace falta, es port-forwarding (DNAT) en el host; si estás reenviando mucho, plantéate si la VM no querrá simplemente una IP pública routed.

Combina libremente: un host típico ejecuta vmbr0 (público, bridged) y un bridge privado para el tráfico backend entre invitados.

VLAN: un bridge, muchas redes

El patrón moderno es el bridge VLAN-aware, una sola flag en vmbr0:

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Ahora el bridge deja pasar el tráfico etiquetado, y fijas el VLAN Tag por tarjeta de red virtual en las opciones de hardware de la VM; el bridge se encarga de etiquetar/desetiquetar, y los invitados no se enteran. Comparado con el estilo antiguo de un bridge por VLAN (vmbr0v40 y compañía), esto es un bridge en vez de una docena, y ningún cambio de configuración del host cuando introduces un VLAN nuevo: asignas una etiqueta nueva y listo. Los invitados que necesiten trunks (una VM de firewall, por ejemplo) también pueden recibir tráfico etiquetado directamente.

Dónde los VLAN se topan con un proveedor de hosting: solo segmentan el tráfico donde la infraestructura transporta las etiquetas. Dentro de tu host, siempre; entre tus servidores, cuando la red privada del proveedor las conserva (la nuestra lo hace; los VLAN sobre la LAN privada son cómo los clientes construyen redes segmentadas multi-host; es también el mecanismo detrás de las DMZ de cliente).

Bonding: dos tarjetas de red, un solo uplink lógico

Los bonds agregan tarjetas de red físicas para redundancia (y a veces ancho de banda). El bond pasa a ser el puerto del bridge:

auto bond0
iface bond0 inet manual
    bond-slaves enp1s0 enp2s0
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports bond0
    ...

La elección de modo es más simple de lo que sugieren las siete opciones, y la documentación oficial es directa: usa 802.3ad (LACP) si tu switch lo soporta; si no, usa active-backup. LACP necesita configuración equivalente en el switch del proveedor (en un servidor dedicado, eso significa que hay que acordarlo con tu proveedor de hosting, no simplemente activarlo en local); active-backup funciona con cualquier switch y aporta failover puro. Ten en cuenta que un único flujo TCP nunca supera la velocidad de un enlace físico bajo LACP; el bonding multiplica el ancho de banda agregado, no el de cada flujo. Y si más adelante formas un clúster: corosync no lleva bien algunos modos de bond; dale al tráfico de clúster su propia tarjeta de red sin bond, o active-backup.

Dónde encaja la capa SDN

Todo lo anterior configura un solo host. La función SDN de Proxmox (funcionalidad núcleo totalmente compatible desde la 8.1, configurada en Datacenter → SDN) aplica definiciones de red para todo el clúster: defines una zona y sus VNets una vez, y cada nodo las ofrece de forma consistente. Los tipos de zona corresponden a distintos niveles de ambición:

• Simple: bridges aislados por nodo con IPAM/DHCP gestionado por el clúster de forma opcional; la versión gestionada de bridge-ports none.
• VLAN: la configuración VLAN de arriba, definida una vez para todo el clúster.
• QinQ: etiquetas VLAN apiladas, para cuando repartes VLAN entre inquilinos.
• VXLAN: redes de capa 2 tunelizadas sobre cualquier conectividad de capa 3 entre nodos; la respuesta estándar a "una sola red privada que abarca servidores que no comparten switch". Ten en cuenta la MTU: VXLAN cuesta 50 bytes de overhead, así que sube la MTU del underlay o baja la del VNet.
• EVPN: VXLAN más un plano de control basado en BGP y enrutamiento distribuido; territorio de fabrics de datacenter.

Regla general: host único o un puñado de bridges estáticos → simplemente /etc/network/interfaces, este artículo. Clúster con más de un par de redes compartidas, o cualquier forma de multiinquilino → defínelas una vez en SDN. (PVE 9 añadió "fabrics", underlays routed autoconfigurados, una señal de hacia dónde va esta capa.)

No dejarte fuera tú mismo

Toda historia de terror sobre redes en Proxmox es la misma historia: un cambio de bridge aplicado a la interfaz que lleva la sesión SSH. Las disciplinas:

• Aplica en caliente, de forma atómica. Edita /etc/network/interfaces, luego ifreload -a (ifupdown2 aplica el delta en caliente). El flujo de cambios pendientes más "Apply Configuration" de la interfaz hace lo mismo, con un paso de revisión.
• Ten la consola lista antes de necesitarla. El acceso IPMI/KVM-over-IP (incluido con nuestros servidores) convierte "me quedé sin uplink al hacer el bridge" de un corte de servicio en un arreglo de dos minutos desde la consola. Verifica tu acceso antes de editar.
• Cambia una capa cada vez. Primero el bond, verifica; luego el bridge sobre el bond; luego los VLAN. Los cambios combinados producen modos de fallo combinados.
• No te dejes el host sin querer detrás del firewall. Proxmox tiene su propio firewall (niveles datacenter → nodo → VM). Cuando lo actives, confirma las reglas de gestión (SSH, 8006) antes de aplicar a nivel de nodo. La misma lógica de bloqueo que en nuestra guía de reglas de firewall básicas, un nivel más arriba.

Preguntas frecuentes

¿Debería usar bridges de Linux u Open vSwitch?

Bridges de Linux, a menos que llegues con un requisito concreto de OVS. Es la vía predeterminada de Proxmox y la mejor documentada; la opción VLAN-aware cubre los casos de segmentación para los que antes se recurría a OVS, y toda la capa SDN está construida sobre bridges de Linux con ifupdown2. OVS sigue siendo compatible para quien necesite sus extras, pero en un despliegue típico de servidor dedicado añade complejidad sin añadir capacidad que vayas a usar.

¿Cómo le doy a una VM su propia IP pública?

Dos formas. Bridged: conecta la VM a vmbr0 y configura una IP adicional que tu proveedor haya asignado a tu servidor (respetando su política de MAC; en nuestra red, las IP adicionales vienen con el servidor y esta es la configuración estándar). Routed: la MAC que ve el proveedor sigue siendo la del host, las VM quedan detrás de un bridge interno, y la subred se enruta hacia ellas. Funciona bajo cualquier política de switch, a costa de que el host se encargue del forwarding.

¿Por qué se cayó la red de mi VM al activar el etiquetado VLAN?

Casi siempre es una de tres causas: el bridge no es VLAN-aware (falta bridge-vlan-aware yes), la ruta física no transporta la etiqueta (el switch del proveedor o la LAN privada debe dejar pasar ese VLAN), o hay un desajuste de MTU al hacer tunneling (los 50 bytes de overhead de VXLAN). Depura en ese orden: primero las flags del bridge, luego el transporte de la etiqueta de extremo a extremo con tcpdump -e vlan, y luego el MTU con un ping do-not-fragment del tamaño del límite.

¿Hace falta un clúster para todo esto?

No. Todo hasta la sección de SDN funciona en un solo host. El propio SDN también funciona en un solo nodo (las zonas Simple con DHCP gestionado son realmente útiles en solitario), pero su valor crece con el número de nodos. Si el clustering está en tu hoja de ruta, la decisión de red que conviene tomar pronto es reservar una tarjeta de red (o al menos un VLAN) para el tráfico de clúster: corosync quiere baja latencia y no tolera bien competir con el tráfico masivo de las VM; más detalles en nuestra guía de clúster y alta disponibilidad.

Desplegar en Serverside

Los patrones de esta guía se corresponden directamente con lo que te da un servidor dedicado Proxmox nuestro: espacio de IP pública adicional para VM bridged, red privada entre tus servidores que transporta tus VLAN (los patrones de segmentación multi-host y DMZ de más arriba), KVM-over-IP para editar la red sin miedo, y mitigación DDoS permanente por delante de todo, aprovisionado con Proxmox VE preinstalado en menos de un minuto sobre el ASN 55285.

Continúa la serie con cómo configurar tus primeras VM y contenedores, LXC vs KVM: cuándo usar cada uno, y estrategias de backup con vzdump y PBS.