Configurar la red de Proxmox VE: modo puente o enrutado, bloques /24 extra, MAC e IPv6
La mayoría de los problemas de los VPS en un nodo host Proxmox VE son problemas de red: VM que no alcanzan su puerta de enlace, un /24 adicional que funciona en el host pero no en las VM, o un IPv6 que nunca responde. La solución depende de cómo su proveedor entrega las direcciones IP. Esta guía explica los dos modelos de entrega habituales, en puente (bridged, on-link) y enrutado (routed), muestra el /etc/network/interfaces correspondiente a cada uno, trata las IP vinculadas a MAC, los bloques /24 adicionales y las subredes IPv6, y explica cómo verificar el resultado y solucionar problemas.
/etc/network/interfaces antes de editarlo y aplique los cambios con ifreload -a mientras todavía pueda acceder a la consola.Paso 1: Averiguar cómo se entregan sus IP
| Modelo de entrega | Cómo se reconoce | Cómo se conectan las VM |
|---|---|---|
| En puente / on-link | El bloque tiene su propia puerta de enlace dentro del bloque (p. ej. 203.0.113.1 para 203.0.113.0/24) en la misma red que su servidor | Las VM en vmbr0 usan directamente la puerta de enlace del proveedor |
| Enrutado | El proveedor enruta el bloque hacia la IP principal de su servidor; no hay puerta de enlace dentro del bloque | El host actúa como router; las VM usan el host como puerta de enlace |
| Vinculado a MAC | Solo la MAC propia del servidor (o las MAC virtuales registradas) puede enviar tráfico para esas IP | Configuración enrutada en el host, o una MAC virtual registrada por cada VM |
La información de entrega de su servidor indica cada bloque de IP con su puerta de enlace y su máscara de red. Si no especifica si un bloque es enrutado u on-link, consulte al soporte antes de configurarlo; adivinarlo le costará horas.
Paso 2: Configuración en puente (puerta de enlace dentro del bloque)
La NIC física pasa a ser un puerto de vmbr0 y la IP propia del host se traslada al puente. Las VM conectadas a vmbr0 quedan en la red del proveedor como si fueran servidores independientes.
# /etc/network/interfaces (main IP 198.51.100.10/24, gateway 198.51.100.1)
auto lo
iface lo inet loopback
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 198.51.100.10/24
gateway 198.51.100.1
bridge-ports eno1
bridge-stp off
bridge-fd 0Un bloque adicional entregado on-link (por ejemplo 203.0.113.0/24 con puerta de enlace 203.0.113.1) no requiere ningún cambio en el host: configure las VM en vmbr0 con una dirección del bloque y la puerta de enlace de ese bloque, p. ej. ip=203.0.113.11/24,gw=203.0.113.1.
Paso 3: Configuración enrutada (bloque enrutado hacia la IP principal)
Cuando el proveedor enruta 203.0.113.0/24 hacia su IP principal, coloque el bloque en un puente interno que no esté conectado a ninguna NIC física, asigne al host la primera dirección como puerta de enlace de las VM y active el reenvío (forwarding).
# /etc/network/interfaces (vmbr0 as in Step 2, plus:)
auto vmbr1
iface vmbr1 inet static
address 203.0.113.1/24
bridge-ports none
bridge-stp off
bridge-fd 0echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/80-forward.conf
sysctl --system
ifreload -aLas VM se conectan a vmbr1 y usan las direcciones 203.0.113.2–254 con la puerta de enlace 203.0.113.1. Como el host ocupa la .1 y las direcciones de red y de broadcast siguen reservadas, un /24 enrutado ofrece 253 direcciones utilizables para VM. El tráfico sale por la interfaz principal del host con las IP de origen propias de las VM; no interviene ningún NAT.
Paso 4: IP vinculadas a MAC
Algunas redes solo aceptan tráfico para sus IP desde la dirección MAC propia del servidor. Cada VM en puente tiene su propia MAC, así que sus paquetes se descartan y parece que "no tienen red" aunque la configuración se vea correcta. Hay dos soluciones:
- Configuración enrutada: pida a su proveedor que enrute el bloque hacia la IP principal de su servidor y aplique el paso 3, de modo que todo el tráfico salga con la dirección MAC propia del host.
- MAC virtuales: si su proveedor las ofrece, solicite una MAC por cada IP y asígnela a la NIC de la VM:
qm set 101 --net0 virtio=02:00:00:AA:BB:CC,bridge=vmbr0.
Paso 5: Subredes IPv6 para las VM
Si una subred IPv6 (por ejemplo un /64 o un /56) está enrutada hacia su host, trátela exactamente igual que el bloque IPv4 enrutado del paso 3: asigne una dirección de la subred a vmbr1, active el reenvío IPv6 y use esa dirección como puerta de enlace de las VM.
# /etc/network/interfaces: add an IPv6 stanza to vmbr1
iface vmbr1 inet6 static
address 2001:db8:200::1/64
echo 'net.ipv6.conf.all.forwarding = 1' > /etc/sysctl.d/81-ipv6-forward.conf
sysctl --system
ifreload -a
# VM configuration (cloud-init)
qm set 101 --ipconfig0 ip=203.0.113.11/24,gw=203.0.113.1,ip6=2001:db8:200::11/64,gw6=2001:db8:200::1Tenga en cuenta que, al activar el reenvío, Linux ignora los anuncios de router (router advertisements) en el enlace de subida, por lo que la ruta IPv6 predeterminada del propio host debe configurarse de forma estática en vmbr0 (un bloque iface vmbr0 inet6 static con address y gateway).
Si, en cambio, su único /64 es on-link en el enlace de subida (el router del proveedor espera encontrar cada dirección directamente mediante neighbour discovery), las VM en un puente separado no serán accesibles a menos que el host responda a neighbour discovery en su nombre (proxy NDP, por ejemplo con ndppd) y el enrutamiento se ajuste con cuidado. La solución más sencilla y fiable es pedir a su proveedor una subred enrutada hacia su host; el soporte de IMIDC puede indicarle qué opción tiene su servidor.
Paso 6: Aplicar y verificar
cp /etc/network/interfaces /root/interfaces.bak.$(date +%F)
ifreload -a
ip -br addr # addresses on vmbr0 / vmbr1
ip route # default route via the provider's gateway
bridge link # which ports and VM taps belong to which bridge
# Watch ARP and traffic for one VM address while it pings out
tcpdump -ni vmbr0 host 203.0.113.11
# From inside the VM
ping -c3 203.0.113.1 # gateway
ping -c3 1.1.1.1 # internet
ping -c3 google.com # DNSSi la VM alcanza la puerta de enlace pero no internet, el upstream está descartando su tráfico (vinculación a MAC, ruta inexistente o máscara de red incorrecta). Si no alcanza la puerta de enlace en absoluto, revise el puente, la IP y el prefijo de la VM, y si el filtro de IP del firewall de Proxmox permite esa dirección.
Preguntas frecuentes
¿Debo usar red en puente o enrutada?
Use la que corresponda al modelo de entrega de su proveedor. El modo puente es el más sencillo cuando el bloque tiene su propia puerta de enlace on-link. El modo enrutado es obligatorio cuando el bloque está enrutado hacia su IP principal, y es la opción más robusta cuando las IP están vinculadas a MAC.
¿Puedo combinar VM con IP pública y VM con NAT en un mismo host?
Sí. Mantenga las VM públicas en vmbr0 o vmbr1 y coloque las VM con NAT en un puente privado aparte, como se describe en red NAT en Proxmox VE.
¿IMIDC entrega los bloques en puente o enrutados?
Depende de la ubicación y del servidor. La puerta de enlace y la máscara de red figuran en su información de entrega; si algo no está claro, abra un ticket y le confirmaremos el modelo y le ayudaremos con la configuración.
¿Sigue sin resolverlo después de seguir estos pasos? Abra un ticket de soporte y el equipo técnico de IMIDC, disponible 24/7, le ayudará. Incluya la IP del servidor host, sus bloques de IP, el contenido de /etc/network/interfaces y la salida de ip -br addr y ip route para que podamos localizar el problema más rápido.