Firewall de Proxmox, VLAN y segmentación: cómo se controla el tráfico

El firewall de Proxmox viene incluido en la plataforma, filtra el tráfico en tres niveles distintos y está apagado de fábrica. Esa combinación explica por qué tantas instalaciones tienen doce máquinas virtuales que se hablan entre sí sin ninguna restricción. Esta guía recorre las dos mitades del problema: primero cómo se separa la red en VLAN, y después cómo se escriben y se depuran las reglas que deciden quién habla con quién.

Los ejemplos usan un caso concreto, con nombres y direcciones reales, para que pueda copiarlo y adaptarlo. No hace falta comprar nada: todo lo que aparece aquí ya está instalado en cualquier nodo.

Dónde encaja esta guía

Es la segunda de cuatro guías construidas sobre el mismo inventario: un clúster de tres nodos con doce máquinas. En la primera se creó ese inventario; aquí se parte en cinco redes separadas.

1. Proxmox — la plataforma, los comandos y el reparto de recursos.
2. Firewall de Proxmox — está leyéndola: VLAN, jerarquía de reglas y control del tráfico.
3. Power Query — llevar el inventario a Excel y dejarlo limpio.
4. Power BI — convertirlo en un tablero que se actualiza solo.

Por dónde entra el tráfico antes de llegar al firewall de Proxmox

Antes de filtrar hay que entender el camino. Una máquina virtual no se conecta al cable: se conecta a un puente, que es un conmutador por software dentro del nodo. Ese puente se llama vmbr0 y tiene una o varias tarjetas físicas conectadas a él.

La configuración vive en /etc/network/interfaces. Proxmox no la escribe directamente: guarda los cambios en /etc/network/interfaces.new y los aplica al pulsar «Aplicar configuración» o con ifreload -a, sin reiniciar el servidor.

# Dos tarjetas agregadas con LACP y un puente troncal encima
auto bond0
iface bond0 inet manual
    bond-slaves enp1s0f0 enp1s0f1
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
    address 10.10.40.11/24
    gateway 10.10.40.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Hay dos modos de agregación que se usan de verdad. LACP (802.3ad) reparte el tráfico entre las dos tarjetas y exige que el conmutador físico esté configurado igual. Activo-respaldo no reparte nada, solo cambia de tarjeta si una falla, y funciona contra cualquier conmutador. Si no hay quien configure el conmutador, el segundo es la elección honesta.

VLAN en Proxmox: las dos formas de hacerlo

Una VLAN es una red separada que viaja por el mismo cable con una etiqueta numérica. Los conceptos básicos están en la guía sobre la red de área local; aquí interesa cómo se aplican dentro del nodo. Proxmox admite dos enfoques y conviene no mezclarlos.

Con el puente compatible con VLAN, asignar una máquina a su red es una sola opción en la tarjeta virtual. El puerto físico va en modo troncal y el nodo se encarga del resto.

# Poner la máquina 102 en la VLAN 30
qm set 102 --net0 virtio,bridge=vmbr0,tag=30,firewall=1

# Un contenedor en la misma red
pct set 108 --net0 name=eth0,bridge=vmbr0,tag=30,ip=dhcp,firewall=1

Fíjese en firewall=1. Sin esa opción, la máquina queda fuera del filtrado por mucho que existan reglas, y es la causa número uno de «escribí la regla y no hace nada».

El plan de segmentación del ejemplo

Segmentar no es repartir máquinas al azar: es agrupar por quién necesita hablar con quién. Las doce máquinas del inventario quedan así.

Las cinco filas suman los 46 vCPU, 164 GiB y 7.200 GiB del inventario completo, que es la comprobación de que ninguna máquina se quedó sin red asignada. Esa suma vuelve a aparecer, calculada de otra forma, en las dos guías siguientes.

La VLAN 99 merece un comentario. Es la red de pruebas y funciona también como cuarentena: si un equipo aparece comprometido, se le cambia la etiqueta y queda aislado sin tocar un solo cable. Ese movimiento dura diez segundos y no requiere ir al rack.

La jerarquía del firewall de Proxmox

Aquí está la idea central de todo el artículo. El firewall de Proxmox no es una lista de reglas, sino tres listas que se aplican en cadena, cada una guardada en su propio archivo dentro del sistema replicado /etc/pve. Como ese sistema se sincroniza entre nodos, una regla del centro de datos llega sola a todos.

El orden importa: las reglas del nodo tienen prioridad sobre las del centro de datos, y las de la máquina se aplican sobre su propio tráfico. El nivel de clúster es el sitio para lo transversal; el de máquina, para lo específico de ese servicio.

Las tres direcciones del tráfico

Cada nivel distingue tres sentidos, y cada uno tiene su política por defecto: ACCEPT, DROP o REJECT.

• In — lo que llega al nodo o a la máquina. Es donde se pone DROP por defecto.
• Out — lo que sale. Suele dejarse en ACCEPT, salvo en entornos muy cerrados.
• Forward — lo que pasa a través, disponible en el nivel de nodo y en el de red virtual.

La diferencia entre DROP y REJECT parece menor y no lo es. DROP descarta en silencio y quien está al otro lado espera hasta agotar el tiempo; REJECT responde que no. Hacia el exterior conviene DROP, porque no confirma que haya algo escuchando. Hacia dentro, REJECT ahorra minutos de diagnóstico.

Los dos interruptores del firewall de Proxmox

Para que una regla tenga efecto sobre una máquina hacen falta dos activaciones independientes, y ninguna implica la otra.

1. El interruptor general, en el centro de datos: enable: 1 dentro de [OPTIONS] en cluster.fw. Mientras esté apagado, no se filtra nada en ningún sitio.
2. La casilla de cada tarjeta virtual: la opción firewall=1 del ejemplo anterior, una por interfaz de red de cada máquina.

Antes de encender el interruptor general conviene una precaución elemental: comprobar que la red de administración está en el conjunto management. Si no lo está, la primera regla que se aplique lo dejará fuera de su propia interfaz web.

# Qué considera el nodo su red local de gestión
pve-firewall localnet

# Reglas realmente generadas, ya resueltas
pve-firewall compile | less

# Estado del servicio
pve-firewall status

Alias, conjuntos y grupos en el firewall de Proxmox

Un archivo con cuarenta reglas llenas de direcciones sueltas es imposible de mantener. El firewall de Proxmox ofrece tres mecanismos para evitarlo, y los tres se declaran en cluster.fw.

• Alias — un nombre para una dirección o una red. sede_bogota en lugar de 190.0.0.0/24.
• Conjunto de direcciones (IPSet) — un grupo de direcciones o redes, que se invoca en una regla con un signo más delante: +admin.
• Grupo de seguridad — un bloque de reglas con nombre, definido una vez y aplicado a muchas máquinas. Es la pieza que más trabajo ahorra.

# /etc/pve/firewall/cluster.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[ALIASES]
sede_bogota 190.0.0.0/24
vlan_gestion 10.10.40.0/24

[IPSET management]
10.10.99.11
10.10.99.12
10.10.99.13
vlan_gestion

[GROUP publicado]
IN ACCEPT -p tcp -dport 443 -log nolog
IN ACCEPT -p tcp -dport 80 -log nolog
IN DROP -log info

[GROUP administracion]
IN ACCEPT -source +management -p tcp -dport 22
IN ACCEPT -source vlan_gestion -p icmp -log nolog

Después, cada máquina solo referencia lo que le toca. Este es el archivo completo del servidor web del ejemplo.

# /etc/pve/firewall/102.fw
[OPTIONS]
enable: 1
policy_in: DROP
log_level_in: info

[RULES]
GROUP publicado
GROUP administracion
IN ACCEPT -source 10.10.20.0/24 -p tcp -dport 5432 -log nolog

Se leen de arriba abajo y gana la primera que coincide. También existen macros con nombre —SSH, HTTP, HTTPS, DNS, Ping— que evitan recordar números de puerto y hacen el archivo mucho más legible para quien lo herede.

Los conjuntos que ya existen sin declararlos

El tercero merece atención en entornos con varios clientes o proveedores. Sin él, cualquiera con acceso a una máquina puede falsear su dirección de origen y hacerse pasar por otra de la misma VLAN.

De la matriz de tráfico a las reglas

Escribir reglas sin haber decidido antes qué se permite es cómo nacen los firewalls llenos de excepciones. El orden correcto es dibujar primero la matriz y traducirla después. Para el inventario del ejemplo queda así.

Tres criterios explican toda la tabla. Lo publicado nunca inicia conversaciones hacia dentro, salvo el puerto exacto que necesita. La gestión llega a todo, porque el monitoreo y las copias no funcionan de otra forma. Y pruebas no habla con nadie, que es justamente el motivo de que exista.

Un detalle que sorprende a quien viene de un firewall perimetral: si las cinco VLAN se enrutan en un equipo externo, ese tráfico entre redes no pasa por el firewall de Proxmox, sino por el enrutador. El filtrado del nodo protege la entrada y la salida de cada máquina, no el encaminamiento entre subredes. Por eso la fila de la VLAN 30 también se traduce en reglas dentro de 102.fw: la defensa se pone lo más cerca posible del servicio.

Diagnóstico del firewall de Proxmox: por qué una regla no actúa

Casi todos los casos que llegan a la mesa de servicio caben en esta lista.

Para ver lo que ocurre de verdad, se sube el nivel de registro con log_level_in: info y se mira el archivo del nodo. Cada línea trae la regla que actuó, así que se sabe cuál coincidió primero.

tail -f /var/log/pve-firewall.log
grep " 102 " /var/log/pve-firewall.log | tail -20

Y una precaución de oficio: cuando se vaya a endurecer un nodo al que solo se llega en remoto, conviene tener a mano el acceso por consola física o por tarjeta de gestión. Cerrarse la puerta desde el otro lado del país es un clásico que solo ocurre una vez.

nftables y el futuro del firewall de Proxmox

El firewall de Proxmox se implementó históricamente sobre iptables. Desde la versión 8.2 existe una implementación paralela sobre nftables, que el propio proyecto mantiene como vista previa tecnológica, es decir, no recomendada todavía para producción. Se activa con nftables: 1 en la configuración del nodo y tiene dos diferencias que hay que conocer: no crea puentes adicionales para el filtrado y no admite REJECT en el tráfico de las máquinas, que pasa a descartarse.

El otro terreno en movimiento es SDN, la capa de redes definidas por software. Permite declarar zonas y redes virtuales desde el centro de datos, en lugar de editar el archivo de red de cada nodo, y las versiones 9 añadieron topologías enrutadas con OSPF y OpenFabric. Tiene sentido cuando hay varios nodos y muchas redes; con tres nodos y cinco VLAN, el puente compatible con VLAN sigue siendo más simple y más fácil de heredar.

Diez decisiones que dejan una red sana

• Separe la red de corosync de la red de datos, con su propia tarjeta.
• Ponga el almacenamiento y las copias en una VLAN que no toque el tráfico de usuarios.
• Use puente compatible con VLAN y etiquete en la tarjeta virtual, no en el puente.
• Empiece con policy_in: DROP y abra lo que haga falta, no al revés.
• Defina grupos de seguridad por rol —publicado, interno, administración— y reutilícelos.
• Mantenga el conjunto management al día antes de tocar nada.
• Registre lo que se descarta durante las dos primeras semanas.
• Documente la matriz de tráfico junto a la configuración, no en la cabeza de alguien.
• Revise que cada tarjeta virtual nueva nazca con firewall=1.
• Pruebe los cambios en la VLAN 99 antes de aplicarlos a la 20.

La segmentación también cambia cómo se resuelven los nombres dentro de la empresa, porque cada red necesita saber a qué servidor preguntar: la guía sobre el servidor DNS cubre esa parte. Y si la red física que hay debajo no está a la altura —conmutadores sin gestión, un solo enlace, cableado improvisado—, ninguna regla lo arregla; ese trabajo es el de redes y conectividad.

Preguntas frecuentes sobre el firewall de Proxmox

¿Sustituye al firewall perimetral?

No, y no intenta hacerlo. El perimetral filtra lo que entra y sale de la empresa, y aporta inspección de contenido. El firewall de Proxmox filtra entre máquinas dentro del mismo centro de datos, que es exactamente el tráfico que el perimetral nunca ve.

¿Se puede activar sin cortar nada?

Sí, si se hace en dos pasos. Primero se enciende con políticas en ACCEPT y el registro activado, para ver qué tráfico existe realmente. Con esa foto se escriben las reglas y solo entonces se cambia la política a DROP.

¿Las reglas sobreviven a una migración?

Sí. Viven en /etc/pve, que se replica en todos los nodos, así que la máquina llega al destino con su filtrado intacto. Es una de las ventajas de que el firewall sea parte de la plataforma y no un añadido por nodo.

¿Cuántas VLAN son demasiadas?

El límite técnico es 4.094 y nunca es el problema. El límite real es cuántas puede mantener el equipo que las opera. Cinco redes bien documentadas protegen más que veinte que nadie recuerda para qué se crearon.

Qué llevarse sobre el firewall de Proxmox

El firewall de Proxmox filtra en tres niveles encadenados, guarda su configuración en archivos que se replican solos y necesita dos interruptores encendidos para actuar. La segmentación en VLAN se apoya en un puente compatible con VLAN y en una etiqueta por tarjeta virtual. Y el trabajo que de verdad decide el resultado no se hace en la consola, sino antes: dibujar la matriz de quién habla con quién.

La siguiente guía saca este inventario del clúster y lo lleva a Excel, donde deja de ser una consulta de consola para convertirse en una tabla que cualquiera puede leer.