Configurar el cortafuegos Proxmox sin perder el acceso

Administra un nodo Proxmox de forma remota. La Web UI responde en TCP 8006, SSH en TCP 22, y la activación del cortafuegos plantea de inmediato la pregunta adecuada: ¿por qué fuente de administración podrás acceder si falta alguna regla?

El procedimiento permanece deliberadamente limitado: consola IPMI, KVM o local, toma del existente, perímetro management, autorizaciones 8006 y 22, compilación, simulación, y luego activación de un solo nivel. Prueba desde una nueva conexión antes de continuar.

n

n nn

El cortafuegos Proxmox actúa en varios niveles

Proxmox distingue los niveles Datacenter, Node y VM/CT. El archivo /etc/pve/firewall/cluster.fw contiene la configuración compartida del clúster. El archivo /etc/pve/nodes/<nodename>/host.fw se refiere a un nodo específico. Las reglas de VM y de contenedor se encuentran en /etc/pve/firewall/<VMID>.fw.

Las reglas del nodo pueden provenir del Datacenter o del archivo de host. El nivel de host tiene prioridad sobre el nivel Datacenter. Para esta primera activación, protege primero el acceso al nodo y no mezcles Datacenter, Node y VM/CT en el mismo cambio.

La documentación Proxmox indica que el cortafuegos está desactivado por defecto a nivel de clúster con enable: 0. Una vez activado, el tráfico hacia los hosts está bloqueado por defecto, excepto por excepciones documentadas como el tráfico local, las conexiones establecidas y ciertos flujos internos. Por lo tanto, el acceso remoto a 8006 o 22 debe basarse en una fuente de administración identificada.

Preparar la consola y evaluar el existente

Antes de cualquier política restrictiva, abre una consola independiente: IPMI, KVM, acceso local o consola proporcionada por el proveedor. Una sesión SSH abierta ayuda a observar el cambio, pero no es un verdadero salvavidas si pasa por la misma red que tu acceso habitual.

Desde el nodo, evalúa el nombre, las direcciones, la ruta y el estado actual del cortafuegos:

hostname
ip -br address
ip route
pve-firewall status

Nota la dirección IP realmente utilizada por tu puesto, tu VPN o tu bastión de administración. No te limites a la IP del nodo: la regla debe reconocer la fuente de la conexión entrante.

Si el camino de administración todavía pasa por un puente Proxmox que debe modificarse, trata esa modificación por separado con la guía sobre la configuración de un puente de red Proxmox. El cortafuegos no debe usarse para corregir simultáneamente un cambio de interfaz o de puerta de enlace.

Definir las fuentes de administración

El IPSet estándar management se aplica a los cortafuegos de los hosts. Puede agrupar la IP pública de administración o el subred del VPN utilizado para la Web UI, VNC, SPICE y SSH. La red de clúster local se agrega automáticamente a través del alias cluster_network para la comunicación entre hosts.

Un ejemplo documental en /etc/pve/firewall/cluster.fw se parece a esto:

[IPSET management]
203.0.113.10
192.0.2.0/24

203.0.113.10 y 192.0.2.0/24 son valores de ejemplo. Reemplázalos por tu fuente real, luego verifica la dirección desde la que abres la nueva sesión. Una IP pública que cambia, un VPN que sale por otro rango o un bastión olvidado son suficientes para hacer que la regla sea inoperante.

No abras 0.0.0.0/0 hacia el puerto 8006 como configuración normal. Esta amplia excepción solo se justifica en un laboratorio aislado y asumido, no en un nodo de producción accesible remotamente.

Permitir Web UI y SSH a nivel de host

Los dos accesos de administración que se deben tratar primero son la Web UI Proxmox en TCP 8006 y SSH en TCP 22. Coloca las reglas a nivel de host o Datacenter según tu organización, reutilizando el IPSet +management.

[RULES]
IN ACCEPT -source +management -p tcp -dport 8006
IN ACCEPT -source +management -p tcp -dport 22

Este bloque ilustra reglas de entrada específicas. Mantén la política de entrada permisiva durante la primera prueba si el IPSet aún no ha sido verificado. El endurecimiento viene después de la prueba de acceso, no antes.

SPICE utiliza TCP 3128 y la consola VNC Web utiliza TCP 5900-5999. Agrega estas necesidades solo si tu administración las utiliza realmente. En un clúster, no rompas tampoco Corosync en UDP 5405-5412 ni la migración en TCP 60000-60050.

El IPSet management se refiere a los hosts. No configura las reglas de las VM y los contenedores. Las reglas IN y OUT detalladas de los invitados siguen siendo otro tema.

Compilar, simular y luego activar un solo nivel

Antes de la activación, muestra las reglas compiladas:

pve-firewall compile
pve-firewall status

pve-firewall status vuelve a leer y compila la configuración completa. Las advertencias que muestra deben solucionarse antes del cambio. Una compilación limpia todavía no prueba que tu fuente remota pueda acceder a 8006 o 22, pero un error de configuración ya es suficiente para detener la secuencia.

Luego puedes simular los dos accesos de administración con la dirección real del administrador y la del nodo:

pve-firewall simulate --from outside --to host --source <IP_ADMIN> --dest <IP_NOEUD> --dport 8006 --protocol tcp
pve-firewall simulate --from outside --to host --source <IP_ADMIN> --dest <IP_NOEUD> --dport 22 --protocol tcp

La simulación prueba las reglas con la fuente, el destino, el puerto y el protocolo proporcionados. No simula la tabla de enrutamiento del núcleo. Por lo tanto, un resultado favorable no reemplaza ni la consola de emergencia ni una prueba real desde una nueva conexión.

Luego activa Datacenter o Node, un solo nivel a la vez, desde Datacenter > Firewall o Node > Firewall. Si usas el archivo de clúster, la activación documentada se escribe:

[OPTIONS]
enable: 1

No pases directamente a los archivos de VM. El primer cambio debe responder a una sola pregunta: ¿se mantiene el acceso de administración del nodo accesible desde la fuente autorizada?

Probar con una nueva conexión

Después de la activación, abre una nueva ventana y carga https://<ip-noeud>:8006/. También inicia una nueva sesión SSH desde la fuente ubicada en management. La antigua sesión permanece abierta durante estos dos controles.

Luego verifica el estado del cortafuegos:

pve-firewall status

En el antiguo backend, iptables-save permite leer las reglas generadas. Úsalo para observar, no para editar directamente las cadenas producidas por Proxmox. El artículo sobre la lectura de las reglas iptables en Linux cubre este control de bajo nivel.

Cierra la antigua sesión solo después de validar la Web UI y una nueva conexión SSH. Si la prueba falla, utiliza la consola independiente para eliminar la regla defectuosa o desactivar la opción en el nivel activado.

Atención: pve-firewall stop retira activamente las reglas Proxmox VE relacionadas con iptables. El host puede quedarse sin protección. Es un gesto de recuperación delimitado, no un estado final recomendado.

Detenerse antes de las reglas de VM

A este punto, has asegurado el orden de activación y verificado el acceso de administración del nodo. Detente aquí si tu objetivo era implementar el cortafuegos Proxmox sin lockout.

• Las reglas detalladas de las VM y contenedores pertenecen al tema dedicado a las reglas de cortafuegos VM Proxmox.
• Una red bloqueada requiere un diagnóstico separado, con su propio perímetro y sus propios controles.
• La lectura detallada de los logs del cortafuegos será objeto de otro artículo.
• El caso de un acceso SSH ya bloqueado no debe mezclarse con esta activación preventiva.

El backend nftables proxmox-firewall sigue siendo una vista técnica según la documentación oficial, con posibles errores o incompatibilidades. No lo elijas como ruta de producción para esta primera activación.

Si una VM pierde después su conectividad, el diagnóstico ya no se refiere al acceso de administración del nodo. Entonces hay que retomar el tema de la red de la VM en el artículo dedicado a la tarjeta de red virtual Proxmox.