Manual — Migración de WireGuard a Cloudflare Zero Trust (WARP)

Introducción

Este tutorial guía a través de la migración de una conexión de red privada basada en WireGuard a Cloudflare Zero Trust (WARP), con el objetivo de eliminar la exposición de puertos y mejorar la seguridad de la red interna. La migración se lleva a cabo en etapas, asegurando que el acceso remoto siga siendo funcional durante todo el proceso.

Objetivo

Reemplazar una conexión de red privada basada en WireGuard con un puerto entrante expuesto por un acceso remoto vía Cloudflare Zero Trust, eliminando todo puerto abierto hacia la red interna.

Arquitectura

La arquitectura propuesta elimina la dependencia de un puerto UDP expuesto y de un servicio DDNS. En su lugar, se utiliza un túnel saliente iniciado por cloudflared en un host interno, conectando directamente a la red interna desde la red de Cloudflare.

Prerrequisitos

• Un host Linux interno para el connector.
• Clientes Linux, Windows y Android.
• Acceso a la cuenta de Cloudflare.
• Un host físico independiente del cluster de virtualización para el connector.

Procedimiento paso a paso

Fase 0 — Prerrequisitos

1. Romper la dependencia circular de credenciales: Exportar los códigos de recuperación de 2FA a soporte offline, verificar que el email de recuperación no dependa de infraestructura propia, y guardar una copia del archivo de configuración de WireGuard de un peer fuera de la infraestructura.

2. Limpieza previa: Revisar los peers de WireGuard y eliminar los que no se usen.

3. Decisiones: Seleccionar un nombre de equipo neutro, elegir el método de autenticación, definir el modo de split tunnel, y decidir si se migrarán servicios de streaming.

Fase 1 — Tenant de Zero Trust

1. En el panel de Cloudflare, entrar a Zero Trust y crear la organización.

2. Elegir el team name. Genera <team-name>.cloudflareaccess.com, que es público.

3. Seleccionar el plan Free (hasta 50 usuarios).

4. Anotar el dominio del equipo — se necesita en cada cliente.

Fase 2 — Connector cloudflared

1. Crear el túnel: En la sección Redes → Túneles, crear un túnel con Cloudflared y copiar el token.

2. Ajustes del host: Configurar los parámetros de red para evitar problemas de throughput y ICMP.

3. Desplegar: Usar un docker-compose.yml para desplegar el connector con el token y verificar los logs.

Fase 3 — Rutas privadas

1. En la sección Redes → Rutas, agregar las rutas CIDR para cada red interna a alcanzar.

2. Verificar que cada ruta apunte al túnel correcto.

Fase 4 — Perfil de dispositivo

1. En Equipo y recursos → Dispositivos → Perfiles de dispositivo, configurar el modo de servicio, protocolo del túnel, split tunnel en modo Include, y el Local Domain Fallback.

2. No tocar opciones como el enrutamiento directo de Microsoft 365 o la instalación de CA en el almacén del sistema.

Fase 5 — Clientes

1. Android: Instalar el cliente desde la tienda, iniciar sesión con el team name, y verificar el kill switch.

2. Windows: Descargar el cliente desde el tenant, instalarlo, iniciar sesión, y verificar la conectividad.

3. Linux: Instalar el cliente desde los repositorios oficiales, iniciar sesión, y verificar la conectividad con comandos como ping, ssh, y dig.

Validación

• Verificar que el acceso remoto funcione desde una red externa, con el WiFi local apagado.
• Realizar pruebas de resiliencia, apagando el hipervisor y verificando que el acceso remoto siga funcionando.
• Mantener el uso real por al menos una semana antes del corte.

Corte

• Deshabilitar la regla del puerto de WireGuard en el firewall.
• Quitar el port-forward en el router del ISP.
• Verificar que el puerto esté cerrado desde el exterior.

Rollback

• Habilitar nuevamente la regla del puerto de WireGuard en el firewall.
• Reinstalar el port-forward en el router del ISP.
• Los clientes WireGuard existentes funcionan sin cambios.

Limitaciones

• Servicios de streaming: No se recomienda usar WARP para streaming de video sostenido, ya que puede violar los términos de servicio de Cloudflare y sumar latencia.
• Dependencia del proveedor: Si la cuenta de Cloudflare se bloquea, se pierde el acceso remoto completo.
• Superficie nueva: El host del connector pasa a ser un pivote hacia la red interna, lo que puede aumentar la superficie de ataque.
• Equipos que no son propios: El cliente WARP instala un servicio de sistema y un adaptador de red virtual, lo que requiere autorización explícita en equipos corporativos o de terceros.

Tabla de decisión o verificación

Bloques de código

sudo tee /etc/sysctl.d/98-quic-buffers.conf > /dev/null << 'EOF'
net.core.rmem_max = 7500000
net.core.wmem_max = 7500000
EOF

echo 'net.ipv4.ping_group_range = 0 2147483647' | sudo tee /etc/sysctl.d/99-cloudflared-icmp.conf
sudo sysctl --system

services:
  cloudflared-warp:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared-warp
    restart: unless-stopped
    network_mode: host
    command: tunnel --no-autoupdate run --token ${TUNNEL_TOKEN}
    env_file: .env

Advertencias

Advertencia: El token del enlace de enrolamiento expira en 60 segundos. Copiarlo, pegarlo y ejecutarlo a mano casi siempre falla por expiración. Si el flujo se demora, regenerarlo:

warp-cli registration delete
warp-cli registration new <team-name>

Advertencia: Si el resolver DNS primario vive en el hipervisor, apuntar el fallback a un resolver secundario que viva en el mismo host que el connector. Así los nombres internos siguen resolviendo cuando el hipervisor está caído — que es justamente cuando más se necesita el acceso.