Problema

En muchos homelabs el único servidor Proxmox (PVE) sirve tanto para máquinas internas como para servicios expuestos al exterior. Cuando se añade un segundo nodo dedicado al DMZ surge la duda: ¿debería el host PVE permanecer en la red de gestión (Management) y solo sus VMs vivir en la DMZ, o mover también el host a la DMZ y bloquear el acceso desde esa zona? La decisión impacta la superficie de ataque, la complejidad de las reglas de firewall y la fiabilidad de backups y monitoreo. El reto es encontrar una arquitectura que limite el daño de una posible fuga de VM sin crear un lab imposible de administrar.

Causa

  1. Fuga de VM (VM escape) – Si una VM logra ejecutar código fuera de su contenedor, el atacante gana acceso al hipervisor. Cuando el host está en Management, ese acceso se extiende a toda la infraestructura interna (NAS, controladores, etc.).
  2. Reglas de firewall mal configuradas – Separar redes implica crear listas de control de acceso (ACL). Un error de ruta o una regla ausente permite tráfico no deseado entre DMZ y Management.
  3. Dependencias de backup/monitoring – Herramientas como vzdump, Prometheus o Zabbix suelen requerir acceso al host desde la red interna. Si el host está aislado en DMZ, esas conexiones pueden fallar o requerir túneles adicionales.
  4. Superposición de VLANs y bridges – En Proxmox es común crear vmbr0 para Management y vmbr1 para DMZ. Un bridge mal configurado puede mezclar tráfico y romper el aislamiento.

Solución

Una arquitectura híbrida que combine lo mejor de ambos enfoques:

  1. Mantener el host PVE en Management pero aislar cada VM en su propia VLAN/bridge DMZ.

    • El host sigue accesible para backups, monitoreo y actualizaciones sin túneles.
    • Cada VM usa un bridge (vmbr1) conectado a la VLAN DMZ y no tiene rutas hacia la VLAN Management.

  2. Aplicar firewall a nivel de host (ufw o iptables) y a nivel de switch (Unifi):

    • En el host, bloquea todo el tráfico entrante desde la VLAN DMZ excepto los puertos estrictamente necesarios (por ejemplo, 22 para SSH desde Management, 8006 para la GUI).
    • En el switch, crea una política “DMZ → Management: DENY” y permite solo los puertos que la VM necesite para salir (p.ej., actualizaciones de paquetes).

  3. Separar los bridges de forma explícita:

    # Bridge para Management (acceso al host)
auto vmbr0
iface vmbr0 inet static
    address 10.0.0.10/24
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0

# Bridge para DMZ (solo VMs)
auto vmbr1
iface vmbr1 inet manual
    bridge_ports eth1
    bridge_stp off
    bridge_fd 0
    • eth0 conectado a la red Management, eth1 a la VLAN DMZ.

  4. Reglas ufw mínimas en el host:

    ufw default deny incoming
ufw default allow outgoing
ufw allow from 10.0.0.0/24 to any port 22 proto tcp   # SSH desde Management
ufw allow from 10.0.0.0/24 to any port 8006 proto tcp # GUI
ufw deny in on vmbr1                                 # Bloquear todo DMZ → host
ufw enable
    • La regla deny in on vmbr1 corta cualquier intento de la DMZ de alcanzar el host, mientras que las reglas explícitas permiten solo lo necesario desde Management.

  5. Backups y monitoreo vía agentes internos:

    • Instala los agentes de backup (p.ej., vzdump) y monitoreo (Prometheus node_exporter) en el host.
    • Configura el servidor de backup en Management para conectarse al host usando la IP de vmbr0. No se necesita abrir puertos en la DMZ.

  6. Opcional: “Jump host” para acceso a VMs DMZ – Si ocasionalmente necesitas entrar a una VM en DMZ, usa un bastión en Management (SSH jump) que tenga acceso a vmbr1. Así evitas exponer directamente la VM al exterior.

Cuándo aplicar esta solución

  • Entornos homelab o pymes donde el número de hosts es bajo y se prefiere una gestión centralizada.
  • Necesitas backups y monitoreo frecuentes sin crear túneles adicionales.
  • Los servicios expuestos (web, API) corren en VMs aisladas y no requieren comunicación directa con la red interna.

No es adecuada cuando:

  • Se dispone de varios hosts PVE en DMZ y la carga de gestión supera lo que un solo nodo Management puede manejar.
  • Política de cumplimiento exige que el hipervisor nunca tenga presencia en la red interna, independientemente de las reglas de firewall.

Código

# Configuración de bridges en /etc/network/interfaces
auto vmbr0
iface vmbr0 inet static
    address 10.0.0.10/24
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0

auto vmbr1
iface vmbr1 inet manual
    bridge_ports eth1
    bridge_stp off
    bridge_fd 0

# Reglas ufw básicas
ufw reset
ufw default deny incoming
ufw default allow outgoing
ufw allow from 10.0.0.0/24 to any port 22 proto tcp
ufw allow from 10.0.0.0/24 to any port 8006 proto tcp
ufw deny in on vmbr1
ufw enable

Verificación

  1. Ping desde Management a la IP del host (vmbr0) – debe responder.
  2. Intento de conexión SSH desde una VM en DMZ al host – debe fallar (Connection refused).
  3. Acceso a la GUI de Proxmox desde una máquina Management – debe abrirse sin problemas.
  4. Backup manual con vzdump – verifica que el archivo se genera en el storage de Management.
  5. Monitoreo – comprueba que Prometheus recoge métricas del host pero no de VMs en DMZ (a menos que se configure un exporter dentro de la VM).

Notas adicionales

  • Revisa la tabla de rutas en el host (ip route) para asegurarte de que la única salida a la VLAN DMZ sea a través de vmbr1.
  • Desactiva IPv6 en los bridges si no lo usas; evita rutas inesperadas.
  • Mantén el firmware del switch actualizado; algunas versiones de Unifi pueden permitir “inter‑VLAN routing” sin reglas explícitas.
  • Documenta cada regla en un archivo de texto dentro del repositorio de configuración (Git). Cuando la red cambie, tendrás un historial claro.
  • Prueba de fuga: ejecuta una VM con qemu-system-x86_64 -enable-kvm -cpu host,... y lanza un proceso que intente leer /dev/kvm. Si el host está bien aislado, el proceso debería fallar.

Con este esquema, el host Proxmox sigue siendo fácil de administrar, los backups y la monitorización permanecen en la zona segura, y cualquier compromiso de una VM queda confinado a la DMZ. La clave está en la combinación de bridges dedicados y reglas de firewall estrictas, sin sobrecargar la arquitectura con túneles innecesarios.