La Bodega Viña Alta tiene tienda, sala de catas y una nave con las barricas. Su servidor con
Proxmox lleva tres invitados: la tienda online (una VM), el grabador de las cámaras de la
nave (un contenedor) y el portal del wifi de los clientes de la sala de catas (otro
contenedor). El servidor tiene dos tarjetas de red: eno1, cableada a la oficina, y eno2,
cableada al switch de las cámaras. Hasta hoy todo iba por la primera. Toca ordenar la red.
Las tarjetas y los bridges
Los invitados no se enchufan a una tarjeta: se enchufan a un bridge (puente), que es un
switch virtual dentro del nodo. El instalador de Proxmox crea uno, vmbr0, mete en él la
primera tarjeta y le pone la IP del nodo (la de la web y ssh). Cada invitado lleva una NIC
virtual enchufada a un bridge, y el bridge la conecta con la tarjeta física, como un switch:
root@pve1:~# ip -br link lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> eno1 UP 3c:ec:ef:2a:80:01 <BROADCAST,MULTICAST,UP,LOWER_UP> eno2 DOWN 3c:ec:ef:2a:80:02 <BROADCAST,MULTICAST> vmbr0 UP 3c:ec:ef:2a:80:01 <BROADCAST,MULTICAST,UP,LOWER_UP> veth102i0@if2 UP aa:1f:b8:3e:c9:0f <BROADCAST,MULTICAST,UP,LOWER_UP> veth103i0@if2 UP 22:09:7c:7e:b9:cf <BROADCAST,MULTICAST,UP,LOWER_UP> tap100i0 UNKNOWN be:c9:89:ef:df:8c <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP>
eno2 está DOWN: no está en ningún bridge, nadie la usa. Cada contenedor encendido pone un
veth (veth102i0: el contenedor 102, su NIC 0) y cada VM un tap (tap100i0). bridge link dice qué hay enchufado a cada bridge (master):
root@pve1:~# bridge link 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 100 5: veth102i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 2 6: veth103i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 2 7: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 2
La IP del nodo no es de eno1: es de vmbr0. La tarjeta solo es un puerto del bridge.
/etc/network/interfaces
Todo esto sale de /etc/network/interfaces, el archivo de ifupdown2 (el que usa Proxmox
para la red). Cada interfaz es una estrofa: auto (levantarla al arrancar), iface NOMBRE inet MÉTODO (static con dirección, manual sin ella) y sus opciones, con un tabulador:
root@pve1:~# cat /etc/network/interfaces auto lo iface lo inet loopback iface eno1 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.80.10/24 gateway 192.168.80.1 bridge-ports eno1 bridge-stp off bridge-fd 0 source /etc/network/interfaces.d/*
bridge-ports son los puertos del bridge (las tarjetas que mete dentro); bridge-stp off y
bridge-fd 0 apagan el spanning tree y su espera, que en un servidor no hacen falta.
En la web es pve1 ▸ System ▸ Network. Lo que se cambia ahí no se aplica al momento:
Proxmox lo escribe en /etc/network/interfaces.new y lo enseña abajo como lo pendiente,
con su diff (lo que se quita, con -; lo que se añade, con +). Dos botones deciden:
- Apply Configuration: lo pendiente pasa a ser el archivo y ifreload -a lo levanta (la tarea SRV networking - Reload). Sin reiniciar.
- Revert: lo pendiente, a la basura.
Desde la shell es lo mismo: se edita /etc/network/interfaces y se aplica con ifreload -a.
Un bridge nuevo
Las cámaras van por eno2, en su red. Para que el grabador las vea, hace falta un bridge en
eno2: Create ▸ Linux Bridge, con Name vmbr1, Bridge ports eno2 y sin IPv4/CIDR:
el servidor no tiene por qué hablar en la red de las cámaras, solo sus invitados. Autostart
marcado (que se levante al arrancar) y un comentario. En la shell, con la API:
root@pve1:~# pvesh create /nodes/pve1/network --iface vmbr1 --type bridge --bridge_ports eno2 --autostart 1 --comments camaras
Queda pendiente. Su diff es el que enseña la web abajo (el mismo que da diff -u):
root@pve1:~# diff -u /etc/network/interfaces /etc/network/interfaces.new --- /etc/network/interfaces 2026-09-15 09:00:00.000000000 +0000 +++ /etc/network/interfaces.new 2026-10-08 08:00:52.000000000 +0000 … @@ -11,5 +24,11 @@ bridge-stp off bridge-fd 0 +auto vmbr1 +iface vmbr1 inet manual + bridge-ports eno2 + bridge-stp off + bridge-fd 0 +#camaras source /etc/network/interfaces.d/*
Y Apply Configuration ▸ Yes (o pvesh set /nodes/pve1/network, lo que hace el botón):
root@pve1:~# ip -br link … eno2 UP 3c:ec:ef:2a:80:02 <BROADCAST,MULTICAST,UP,LOWER_UP> … vmbr1 UP 3c:ec:ef:2a:80:02 <BROADCAST,MULTICAST,UP,LOWER_UP>
Ejercicio
La red de las cámaras
Las cámaras de la nave de barricas van por la segunda tarjeta del servidor (eno2), en una red aparte. Crea un bridge vmbr1 en eno2, sin IP (el servidor no habla en esa red: solo los invitados), con el comentario camaras. Y aplícalo.
Encendiendo el nodo…
Cada invitado, en su bridge
La NIC de cada invitado dice a qué bridge va: bridge=vmbr0 en su net0. En la web, en la
Network de un contenedor o en el Hardware de una VM: Edit y otro Bridge. Con el
invitado encendido, se cambia en caliente: su veth (o su tap) pasa al otro bridge al momento.
root@pve1:~# pct set 102 --net0 name=eth0,bridge=vmbr1,ip=dhcp
root@pve1:~# bridge link 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 100 3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr1 state forwarding priority 32 cost 100 6: veth103i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 2 7: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 2 9: veth102i0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr1 state forwarding priority 32 cost 2
Ejercicio
El grabador, con las cámaras
El grabador de las cámaras (el contenedor 102) está en vmbr0, la red de la oficina, y desde ahí no ve las cámaras. Pásalo a vmbr1, el bridge de la nave (ya está hecho), sin apagarlo.
Encendiendo el nodo…
VLAN: varias redes por un cable
Una VLAN separa redes que van por el mismo cable: cada trama lleva una etiqueta (802.1Q) con el número de su VLAN, y los switches solo la entregan en los puertos de esa VLAN. El wifi de los clientes de la sala de catas va en la VLAN 30, por el mismo cable que la oficina.
Para que un bridge entienda etiquetas tiene que ser VLAN-aware: en la web, Edit de vmbr0 y
la casilla VLAN aware (y aplicar). En el archivo son dos líneas: bridge-vlan-aware yes y
bridge-vids 2-4094 (las VLAN que deja pasar). Luego, cada NIC dice su VLAN con su etiqueta
(VLAN Tag, tag=30): el bridge le quita la etiqueta al entrar y se la pone al salir; el
invitado ni se entera.
root@pve1:~# pct set 103 --net0 name=eth0,bridge=vmbr0,ip=dhcp,tag=30
root@pve1:~# pct config 103 … net0: name=eth0,bridge=vmbr0,hwaddr=BC:24:11:E0:5D:D6,ip=dhcp,tag=30,type=veth …
bridge vlan show enseña las VLAN de cada puerto: la tarjeta, troncal (todas, del 2 al 4094,
con la 1 sin etiqueta), y el veth del portal, solo en la 30 (PVID: la suya).
root@pve1:~# bridge vlan show | head -4 port vlan-id eno1 1 PVID Egress Untagged 2 3
Ejercicio
El wifi de los clientes
El wifi de la sala de catas lleva a los clientes por la VLAN 30, por el mismo cable que la oficina. Haz vmbr0 VLAN-aware (aplicado: sin perder su IP) y pon el portal del wifi (el contenedor 103) en la VLAN 30.
Encendiendo el nodo…
El firewall de Proxmox
Proxmox trae un firewall en tres niveles, cada uno con sus reglas y sus opciones:
- Datacenter (
/etc/pve/firewall/cluster.fw): el interruptor general y las reglas del nodo. - Nodo (
/etc/pve/nodes/pve1/host.fw): las del propio servidor. - Cada VM o contenedor (
/etc/pve/firewall/VMID.fw): lo que le llega a ese invitado.
Viene apagado. Para que filtre a un invitado hacen falta tres cosas: el del datacenter
encendido, el del invitado encendido (Firewall ▸ Options ▸ Firewall) y la casilla Firewall
en su NIC. Con la casilla, Proxmox mete la NIC en un bridge propio (fwbr100i0) donde filtra:
root@pve1:~# ip -br link … tap100i0 UNKNOWN fe:97:e4:96:15:87 <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> fwbr100i0 UP d2:a0:1c:e4:59:dd <BROADCAST,MULTICAST,UP,LOWER_UP> fwpr100p0@fwln100i0 UP a2:62:9d:0f:5f:ac <BROADCAST,MULTICAST,UP,LOWER_UP> fwln100i0@fwpr100p0 UP fa:aa:d6:16:42:07 <BROADCAST,MULTICAST,UP,LOWER_UP>
Las reglas se leen de arriba abajo y gana la primera que casa: Direction (in, lo que
entra), Action (ACCEPT, DROP, REJECT), y qué casa: Source, Protocol, Dest. port… o
una macro (HTTP, HTTPS, SSH, DNS: los puertos de cada servicio, ya hechos). Si ninguna
casa, decide la política (Input Policy): en un invitado, DROP. Una regla nueva va
arriba, y sin Enable marcado no hace nada. Source puede ser una red o una sola
dirección: IN SSH(ACCEPT) -source 198.51.100.23 abre ssh a ese equipo y a nadie más (a los
demás, si ninguna otra regla casa, la política).
root@pve1:~# cat /etc/pve/firewall/100.fw [OPTIONS] enable: 1 [RULES] IN HTTPS(ACCEPT) IN HTTP(ACCEPT)
Ejercicio
La tienda, solo la web
La tienda online (la VM 100) está abierta a todo: a la base de datos, a ssh… El firewall del datacenter ya está encendido. Haz que a la tienda solo le llegue la web: 80 y 443 de entrada, nada más.
Encendiendo el nodo…
Encenderlo sin quedarse fuera
Al encender el del datacenter, lo que llega al nodo también se filtra, con la política de entrada del datacenter: DROP. Para no dejarse fuera, Proxmox abre solo la web (8006) y ssh (22) a su red local, la que detecta:
root@pve1:~# pve-firewall localnet local hostname: pve1 local IP address: 192.168.80.10 network auto detect: 192.168.80.0/24 using detected local_network: 192.168.80.0/24
La oficina de la bodega está en otra red (192.168.20.0/24, unidas por el router): para ella
no hay excepción. Las reglas, antes de encenderlo:
root@pve1:~# cat /etc/pve/firewall/cluster.fw [OPTIONS] enable: 1 [RULES] IN SSH(ACCEPT) -source 192.168.20.0/24 # ssh IN ACCEPT -source 192.168.20.0/24 -p tcp -dport 8006 # web
root@pve1:~# pve-firewall status Status: enabled/running
Ejercicio
El firewall del datacenter
Enciende el firewall del datacenter. Cuidado: la oficina está en otra red (192.168.20.0/24), y Proxmox solo deja entrar sin reglas a la web y a ssh desde la red del propio servidor. La web (8006) y ssh (22) tienen que seguir entrando desde la oficina.
Encendiendo el nodo…
Cuando vmbr0 se rompe
Aplicar un vmbr0 mal (sin su dirección, o con el puerto que no es) deja el nodo sin red: la
web no contesta, ssh tampoco, y no hay botón que lo arregle desde fuera. Queda la consola del
propio servidor: su monitor y su teclado (o la consola remota de la placa: iDRAC, iLO, IPMI).
Ahí se arregla /etc/network/interfaces a mano (con nano) y se aplica con ifreload -a:
root@pve1:~# ifreload -a
ip -br a y bridge link dicen si vmbr0 volvió con su IP y su tarjeta.
Si ssh contesta pero la web no (o da errores), no es la red: son sus servicios, como en el tema 1.
La web la sirve pveproxy en el 8006, con pvedaemon y pve-cluster detrás: por ssh,
systemctl status pveproxy dice cómo está, y systemctl start pveproxy lo arranca.
Ejercicio
El servidor, sin red
Alguien cambió el puerto de vmbr0 a eno2 (la tarjeta de las cámaras) y lo aplicó: el servidor se quedó sin red, la web no contesta y ssh tampoco. Estás en su consola (su monitor y su teclado). Arregla /etc/network/interfaces (vmbr0 en eno1, con 192.168.80.10/24) y aplícalo.
Encendiendo el nodo…
Resumen
- Los invitados se enchufan a bridges (switches virtuales);
vmbr0lleva la primera tarjeta y la IP del nodo.ip -br linkybridge linkenseñan lo enchufado. - La red está en
/etc/network/interfaces. Lo de la web queda pendiente (interfaces.new, con su diff) hasta Apply Configuration (ifreload -a) o Revert. - Un bridge sin IP sirve para que los invitados vayan a otra red sin que el nodo hable en ella.
- Con el invitado encendido, su NIC cambia de bridge en caliente; el bridge tiene que existir.
- Un bridge VLAN-aware deja pasar etiquetas; cada NIC dice su VLAN con su VLAN Tag.
- El firewall tiene tres niveles (datacenter, nodo, invitado); a un invitado lo filtra si están encendidos el del datacenter y el suyo y su NIC lleva la casilla Firewall. Gana la primera regla que casa; si ninguna, la política (DROP de entrada).
- Al encenderlo, solo la red local del nodo entra sin reglas a la web y a ssh: las demás redes, con sus reglas antes.
- Un
vmbr0roto se arregla desde la consola del servidor: el archivo a mano eifreload -a.