INFRASTRUCTURE2026.03.21·15 min de lectura

Proxmox + Tailscale: cluster privado sobre red pública

Arquitectura para nodos remotos con cifrado en tránsito, sin exponer puertos públicos. Failover, replicación y backups verificados.

Por qué esta combinación

Proxmox Cluster fue diseñado para LAN. Cuando intentas hacer cluster entre dos data centers o entre on-prem y un VPS público, te enfrentas con: corosync gritando por latencia, puertos expuestos en internet, y configuración de IPSec dolorosa. Tailscale (basado en WireGuard) resuelve los tres problemas con una mesh privada cifrada y mantiene latencias razonables.

Topología

PANAMÁ DC FRANKFURT VPS ┌─────────────┐ ┌──────────┐ │ pve-pa-01 │ ──── tailscale ───── │ pve-eu-01│ │ pve-pa-02 │ ──── WireGuard ──── │ │ │ pve-pa-03 │ (mesh privada) └──────────┘ └─────────────┘ │ │ │ corosync over tailnet0 │ └────────────── ring 0 ──────────────┘ Sin puertos públicos. Cero ingress en firewalls. Latencia P95: 89ms PA → EU (suficiente para HA async).

Setup mínimo del tailnet

# En cada nodo Proxmox
curl -fsSL https://tailscale.com/install.sh | sh

# Auth con tag para ACLs
tailscale up \
  --advertise-tags=tag:proxmox \
  --hostname=pve-pa-01 \
  --accept-routes=false

# Verificar que cada nodo se ve por su IP 100.x
tailscale status

ACL en Tailscale para aislar el cluster

{
  "tagOwners": {
    "tag:proxmox": ["[email protected]"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["tag:proxmox"],
      "dst": ["tag:proxmox:*"]
    },
    {
      "action": "accept",
      "src": ["group:soc"],
      "dst": ["tag:proxmox:8006"]
    }
  ],
  "ssh": [
    {
      "action": "check",
      "src": ["group:admin"],
      "dst": ["tag:proxmox"],
      "users": ["root"]
    }
  ]
}

Configurar corosync sobre tailnet

El truco: en /etc/pve/corosync.conf, usar las IPs 100.x.x.x de Tailscale en vez de las IPs públicas o LAN. Esto fuerza el tráfico de cluster por el túnel cifrado.

nodelist {
  node {
    name: pve-pa-01
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 100.64.0.10
  }
  node {
    name: pve-pa-02
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 100.64.0.11
  }
  node {
    name: pve-eu-01
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 100.64.0.20
  }
}

totem {
  cluster_name: ciberpty-prod
  config_version: 4
  transport: knet
  link_mode: passive
}

Importante Para clusters cross-region, usa replicación storage asíncrona (zfs-send + cron). HA síncrona sobre 80+ ms de latencia sufre. Mejor: failover manual con replicación cada 5 minutos para VMs críticas.

Replicación ZFS verificada

# Snapshot + send incremental cada 5 min
pvesr create-local-job 100-0 pve-eu-01 \
  --schedule "*/5" \
  --rate 50 \
  --comment "VM 100 cross-region async"

# Verificación de integridad post-replicación
zfs list -t snapshot rpool/data/vm-100-disk-0 | tail -3
zfs get -H -o value compressratio rpool/data/vm-100-disk-0

Backups verificados

Backup a Proxmox Backup Server, también accesible solo por tailnet. Verificación automática semanal con proxmox-backup-client benchmark y restore de prueba mensual a un namespace separado.

Un backup que nunca probaste a restaurar no es un backup. Es esperanza con timestamp.

Métricas de la implementación real

Puertos públicos expuestos: 0
Latencia cluster P95: 89ms (PA ↔ EU)
Tiempo de failover manual probado: ~3 minutos para VMs críticas
RPO con replicación cada 5 min: ≤ 5 minutos
RTO probado mensualmente con drill: ~12 minutos

Si manejas infraestructura distribuida y quieres un cluster privado robusto sin VPN dolorosa, podemos diseñar e implementar la arquitectura sobre tu hardware.

→ Solicitar diagnóstico