Problema

Muchos entornos de homelab o pequeñas oficinas dependen de un único enlace de Internet que, por limitaciones del ISP, ofrece ancho de banda insuficiente para varios equipos simultáneos. Cuando se habilita un túnel VPN como Cloudflare WARP en una máquina, la velocidad mejora notablemente, pero solo esa máquina se beneficia. La necesidad típica es proporcionar esa mejora a todos los servidores y contenedores sin instalar WARP en cada uno, manteniendo al mismo tiempo una política de “corte total” si el túnel falla.

Causa

  1. Rutas estáticas por host – Instalar WARP en cada VM genera rutas locales que no se comparten. Cuando el número de máquinas crece, la gestión se vuelve impracticable.
  2. Falta de aislamiento de firewall – Un router que depende de la interfaz WAN del host permite que el tráfico salga directamente si el túnel se cae, lo que rompe la política de “no‑escape”.
  3. Configuración de MTU incompatible – Cloudflare WARP usa una MTU de 1280 bytes. Si la red interna mantiene una MTU mayor, los paquetes fragmentados se pierden y la conectividad se degrada.
  4. Servicios que crean sus propias tablas nftables – warp‑svc inserta una tabla warp automáticamente, lo que puede sobrescribir reglas personalizadas si no se planifica una estrategia aditiva.
  5. DHCP/DNS no centralizado – Sin un servidor DHCP/DNS dentro del túnel, los clientes pueden seguir usando los resolvers del ISP, perdiendo la ventaja de la latencia reducida que ofrece WARP.

Solución

Implementar un contenedor LXC sin privilegios que actúe como router dedicado:

  1. Crear una bridge VLAN en el host Proxmox y asignarle la etiqueta VLAN que se quiere encapsular (por ejemplo, 1111).
  2. Instalar Cloudflare WARP dentro del LXC. El servicio crea su propia tabla warp; todas las reglas del contenedor deben añadirse a esa tabla para evitar colisiones.
  3. Ejecutar dnsmasq + AdGuard Home en el mismo contenedor. dnsmasq gestiona DHCP en la subred de la VLAN, mientras que AdGuard Home proporciona resolución DNS segura y filtrado opcional.
  4. Configurar nftables con una política drop por defecto y reglas explícitas que solo permitan tráfico desde la bridge VLAN hacia la interfaz warp. De esta forma, si el túnel desaparece, el contenedor no reenviará paquetes a la red del ISP.
  5. Ajustar la MTU anunciada en los Router Advertisements (RA) a 1280‑1300 bytes, de modo que los clientes adapten su MTU antes de enviar tráfico al túnel.
  6. Programar un reinicio periódico del proceso warp-svc mediante cron. La memoria de warp‑svc tiende a crecer con el tiempo; un reinicio semanal mantiene el consumo estable sin interrumpir el flujo de tráfico.

Esta arquitectura es reutilizable: basta cambiar la etiqueta VLAN y el rango DHCP para crear nuevos “segmentos” que también pasen por WARP.

Cuándo aplicar esta solución

  • Entornos con un único enlace de salida que necesita ser compartido entre varias máquinas virtuales o contenedores.
  • Política de “corte total”: se requiere que, si el túnel falla, el tráfico no se desvíe a la red del ISP.
  • Necesidad de DNS centralizado bajo el mismo túnel (por ejemplo, para evitar filtrado ISP).
  • Limitaciones de MTU en la red del ISP que hacen que los paquetes fragmentados se pierdan.

No es apropiado cuando:

  • Cada host ya dispone de su propio túnel y la gestión centralizada no aporta valor.
  • La infraestructura de red ya incluye un router físico con capacidad de VPN y reglas de firewall avanzadas.

Código

# 1. Crear bridge VLAN en el host Proxmox
cat <<EOF > /etc/network/interfaces.d/vlan1111.cfg
auto vmbr1
iface vmbr1 inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    vlan-raw-device eth0
    vlan-id 1111
EOF
systemctl restart networking

# 2. Dentro del LXC: instalar warp, dnsmasq y AdGuard Home
apt update && apt install -y cloudflare-warp dnsmasq curl
curl -sSL https://github.com/AdguardTeam/AdGuardHome/releases/latest/download/AdGuardHome_linux_amd64.tar.gz | tar xz -C /opt
/opt/AdGuardHome/AdGuardHome -s install

# 3. Configurar warp (aceptar términos y registrar)
warp-cli register
warp-cli set-mode proxy
warp-cli connect

# 4. nftables: política drop y regla de forward a warp
cat <<'EOF' > /etc/nftables.conf
table inet warp {
    chain forward {
        type filter hook forward priority 0; policy drop;
        iifname "vmbr1" oifname "warp0" accept
        iifname "warp0" oifname "vmbr1" accept
    }
}
EOF
systemctl enable --now nftables

# 5. dnsmasq: DHCP para la VLAN 1111 (subred 10.111.1.0/24)
cat <<EOF > /etc/dnsmasq.conf
interface=vmbr1
dhcp-range=10.111.1.10,10.111.1.200,12h
dhcp-option=option:router,10.111.1.1
dhcp-option=option:mtu,1300
server=1.1.1.1#53
EOF
systemctl restart dnsmasq

# 6. Cron: reinicio semanal de warp-svc
(crontab -l 2>/dev/null; echo "0 3 * * 0 systemctl restart warp-svc") | crontab -

Verificación

  1. Conectividad del cliente

    • Asigna la VLAN 1111 a la interfaz de una VM o contenedor.
    • Verifica que recibe una IP dentro del rango 10.111.1.0/24.
    • Ejecuta ping 1.1.1.1 y comprueba que la latencia corresponde al túnel WARP (≈ 30 ms desde Vietnam).

  2. Política de corte

    • Detén warp-cli disconnect dentro del LXC.
    • Intenta hacer ping a cualquier dirección pública desde la VM. El ping debe fallar inmediatamente, confirmando que el tráfico no sale por la interfaz física.

  3. MTU

    • En la VM, ejecuta ping -M do -s 1270 1.1.1.1.
    • Si los paquetes llegan sin fragmentación, la MTU está bien anunciada.

  4. Consumo de memoria

    • Observa systemctl status warp-svc antes y después del reinicio programado. La memoria debería volver a valores bajos (< 50 MiB).

Notas adicionales

  • Orden de carga: nftables debe iniciarse antes que warp-cli para que la tabla warp exista cuando el servicio añada sus reglas.
  • Persistencia de la bridge: en Proxmox, cualquier cambio manual en /etc/network/interfaces.d/ se sobrescribe al actualizar el host; guarda una copia de seguridad y usa hooks de LXC si necesitas automatizar la recreación.
  • AdGuard Home puede usar la interfaz warp0 como upstream DNS para que las consultas también se beneficien del túnel.
  • Depuración: nft list ruleset muestra la tabla warp. Si ves reglas con counter en cero, probablemente la interfaz de origen/destino no coincide con los nombres reales (vmbr1 vs vethXYZ).
  • Escalado: para múltiples VLANs, replica la bridge y ajusta el rango DHCP; el mismo contenedor puede manejar varios segmentos siempre que la tabla warp tenga reglas iifname/oifname para cada bridge.