Problema

En muchos homelabs se busca maximizar la relación costo‑beneficio usando la menor cantidad de hardware posible. Un escenario típico es ejecutar un router OpenWrt como máquina virtual dentro de Proxmox y, al mismo tiempo, habilitar la replicación ZFS y la alta disponibilidad (HA) del propio clúster. La pregunta que surge con frecuencia es: ¿es más fiable un router virtualizado dentro del clúster HA que un router físico dedicado?

El problema subyacente es la necesidad de mantener conectividad de red incluso cuando una o más piezas de hardware fallan, sin perder acceso remoto para diagnóstico y reparación.

Causa

Los fallos que ponen a prueba la arquitectura suelen provenir de tres áreas:

  1. Punto único de falla (SPOF) en la capa de red – Un router físico aislado no está protegido por la lógica de HA del clúster; si su fuente de alimentación o NIC falla, todo el tráfico se cae.
  2. Dependencia de la capa de virtualización – Un VM de router depende del hipervisor, del almacenamiento compartido y de la red de gestión. Si el nodo que aloja la VM pierde conectividad de gestión o el pool ZFS se desincroniza, la VM puede quedar inaccesible.
  3. Configuración de failover incompleta – Incluso con keepalived o VRRP, si la sincronización de estado (por ejemplo, tablas de NAT o reglas de firewall) no se replica, el nodo secundario no puede asumir el tráfico sin intervención manual.

En la práctica, la combinación de estos factores determina si el router virtualizado se comporta como un componente robusto o simplemente traslada el SPOF a otra capa.

Solución

Una arquitectura resiliente combina dos routers (uno físico y otro virtual) y un mecanismo de failover que opere a nivel de capa 3. La solución se divide en tres bloques:

1. Redundancia física + lógica

  • Router dedicado: Mantén un dispositivo físico (OpenWrt, pfSense, o un router de nivel empresarial) conectado directamente a la WAN y a la red interna.
  • Router virtual: Implementa una VM con la misma imagen (OpenWrt, VyOS, etc.) dentro del clúster Proxmox. Asigna al menos dos interfaces virtuales: una para la WAN (passthrough de la NIC del nodo) y otra para la LAN (vSwitch conectado al bridge del clúster).

2. Sincronización de estado

  • Keepalived/VRRP: Configura ambos routers para anunciar el mismo VIP (Virtual IP) en la LAN. El router físico actúa como MASTER, el virtual como BACKUP.
  • Persistencia de NAT y firewall: Usa iptables-save/iptables-restore o la funcionalidad de “sync” de VyOS para replicar reglas cada vez que cambien. Automatiza la exportación a un directorio compartido en ZFS (/mnt/pool/router-config) y carga en el arranque.

3. Integración con Proxmox HA

Proxmox permite marcar la VM como recurso HA. Cuando el nodo que ejecuta la VM falla, el gestor de clúster (corosync/pacemaker) lanza la VM en otro nodo y keepalived toma el rol de MASTER automáticamente. La configuración mínima en Proxmox es:

pvesh create /cluster/ha/resources \
  --id vmrouter \
  --type vm \
  --sid 101 \
  --max_restart 3 \
  --max_restart_interval 300

Donde 101 es el VMID del router virtual. Con esto, la VM se reinicia automáticamente en cualquier nodo con recursos disponibles.

4. Monitoreo y alertas

  • Prometheus node_exporter + blackbox_exporter para ping al VIP.
  • Alertmanager para notificar cuando el MASTER cambia o cuando la VM no arranca.

Cuándo aplicar esta solución

Señales de que necesitas la arquitectura dual

  • Fallos recurrentes de hardware (fuentes de poder, NICs) en el nodo de gestión.
  • Requerimientos de acceso remoto 24/7: no puedes permitir que la pérdida del nodo de Proxmox te deje sin consola de gestión.
  • Uso intensivo de NAT/DHCP que no tolera reinicios prolongados.

Escenarios donde la solución es excesiva

  • Laboratorios de pruebas temporales sin dependencia de acceso externo.
  • Infraestructura con un único ISP y sin SLA que justifique la complejidad añadida.
  • Entornos donde el presupuesto es tan limitado que no se puede adquirir al menos una NIC de reserva.

Código

# keepalived.conf (fragmento)
vrrp_instance VI_1 {
    state MASTER
    interface eth0          # LAN bridge
    virtual_router_id 51
    priority 150            # físico = 150, virtual = 100
    advert_int 1
    virtual_ipaddress {
        192.168.1.10/24 dev eth0 label eth0:vip
    }
    track_interface {
        eth0
    }
}

Este fragmento muestra cómo el router físico declara prioridad mayor; el virtual tiene priority 100 y asumirá el VIP cuando el MASTER desaparezca.


## Verificación
1. **Comprobar VIP activo**  
   ```bash
   ip -4 addr show dev eth0 | grep 192.168.1.10

El VIP debe aparecer en la interfaz del router que tenga el rol MASTER.

  1. Simular fallo del nodo físico

    • Apaga la VM del router virtual (qm stop 101) y verifica que el VIP sigue en el router físico.
    • Apaga el nodo que aloja la VM (o desconecta la NIC del router físico) y confirma que el VIP pasa al router virtual en menos de 3 segundos.

  2. Revisión de logs

    journalctl -u keepalived -f

    Busca mensajes “Transition to MASTER” y “Transition to BACKUP”.

  3. Alertas
    Verifica que Prometheus recoge el estado del VIP y que Alertmanager envía una notificación al cambiar de MASTER.

Notas adicionales

  • Passthrough de NIC: Para que el router virtual tenga acceso directo a la WAN, usa PCI passthrough de la NIC del nodo. Evita la capa de virtual switch para la WAN, ya que añade latencia y un punto de falla adicional.
  • ZFS snapshots: Programa snapshots diarios del pool que contiene la configuración del router (zfs snapshot pool/router-config@$(date +%F)). En caso de corrupción, restaura rápidamente.
  • Tiempo de conmutación: Keepalived con advert_int 1 y priority diferencia de 50 suele lograr <2 s de failover. Ajusta según la tolerancia de tus servicios.
  • Pruebas regulares: Programa un cron job que desactive temporalmente la interfaz del router físico y registre la latencia del failover. Esto asegura que la solución sigue operativa después de actualizaciones de Proxmox o del firmware del router.

Con esta combinación de hardware dedicado, router virtual en HA y sincronización de estado, se elimina el SPOF tradicional y se gana la flexibilidad de gestionar la red desde cualquier nodo del clúster, incluso cuando una pieza de hardware falla. La clave está en no confiar únicamente en una capa; la redundancia física y lógica debe complementarse para lograr una verdadera alta disponibilidad en entornos homelab.