VPNCloud: Construyendo nuestra propia red privada en la nube

Estado del proyecto a septiembre de 2026. VPNCloud está escrito en Rust. La última versión — 2.3.0 del 23 de diciembre de 2021, los últimos cambios en el repositorio — marzo de 2024. El proyecto no está archivado, pero en la práctica no se desarrolla. Para una red nueva es más sensato tomar soluciones activamente mantenidas de la serie «Mesh VPN»: qué es una red mesh en WireGuard, Tailscale, ZeroTier y NetBird, Headscale o WireGuard manualmente. El artículo será útil para quienes ya usan VPNCloud.

VPNCloud — una VPN mesh peer-to-peer sobre UDP con cifrado y traversión de NAT. Cada nodo de la red puede intercambiar datos directamente con cualquier otro, sin un servidor central por el que pase todo el tráfico. Los nodos agrupan servidores en diferentes nubes, equipos domésticos y de oficina, placas únicas como Raspberry Pi.

Para qué sirve

• Acceso a recursos domésticos y de oficina — servidor de archivos, cámaras, servicios internos — como si estuvieras en la red local.
• Conexión de servidores entre distintos proveedores por direcciones privadas.
• Aislamiento de servicios: parte de la infraestructura es accesible solo dentro de la VPN.
• Nodos detrás de NAT: no todos los nodos necesitan una dirección pública; basta con un nodo accesible por el que los demás se encuentren.

Cómo funciona

VPNCloud transmite datos por UDP. Para la primera conexión un nodo necesita la dirección de al menos otro nodo (peers). Al enterarse de la red a través de él, los nodos establecen conexiones directas entre sí, incluso a través de NAT. En cada nodo se crea una interfaz virtual:

• tun (por defecto) transmite paquetes IP — red de capa 3;
• tap transmite tramas Ethernet — red de capa 2, pasan ARP y DHCP.

El modo de funcionamiento (mode) determina cómo el nodo elige el destinatario: hub envía todo a todos, switch recuerda direcciones MAC, router envía paquetes según las subredes anunciadas por los nodos. El valor por defecto normal significa switch para tap y router para tun.

Instalación

Paquetes listos .deb y .rpm (amd64, arm64, armhf, armel, i386) y binarios estáticos están en la página de releases en GitHub. Ejemplo para Debian o Ubuntu en amd64:

wget https://github.com/dswd/vpncloud/releases/download/v2.3.0/vpncloud_2.3.0_amd64.deb
sudo apt install ./vpncloud_2.3.0_amd64.deb
vpncloud --version

El paquete instala la plantilla del servicio systemd vpncloud@.service: la configuración de la red se guarda en /etc/vpncloud/NOMBRE.net, el servicio se inicia como vpncloud@NOMBRE.

Formato de configuración

La configuración es un archivo YAML. A continuación los principales parámetros según el ejemplo del repositorio del proyecto (assets/example.net.disabled):

Los parámetros network y crypto: aes256, que aparecen en instrucciones antiguas, no existen en el formato 2.x: la red se separa mediante contraseña o claves.

Escenario 1: dos servidores

Dos servidores con direcciones públicas 203.0.113.1 y 203.0.113.2 se unen en la red 10.10.10.0/24.

Servidor A, archivo /etc/vpncloud/mesh.net:

listen: 3210
peers:
  - 203.0.113.2:3210
crypto:
  password: "contraseña-larga-aleatoria"
ip: 10.10.10.1/24

El servidor B difiere solo en la dirección del vecino y su IP:

listen: 3210
peers:
  - 203.0.113.1:3210
crypto:
  password: "contraseña-larga-aleatoria"
ip: 10.10.10.2/24

Inicio y activación automática en cada servidor:

sudo systemctl enable --now vpncloud@mesh
ip addr show vpncloud0
ping 10.10.10.2   # desde el servidor A

El puerto 3210/UDP debe estar abierto en el cortafuegos de ambos servidores.

Escenario 2: nodos detrás de NAT

Un equipo doméstico y un servidor de oficina están detrás de NAT; el servidor en la nube 203.0.113.10 tiene dirección pública. El servidor en la nube se convierte en el punto de conexión inicial:

# servidor en la nube
listen: 3210
peers: []
crypto:
  password: "contraseña-larga-aleatoria"
ip: 10.10.10.10/24

# equipo doméstico (el servidor de la oficina tiene su propio ip, por ejemplo 10.10.10.200/24)
listen: 3210
peers:
  - 203.0.113.10:3210
crypto:
  password: "contraseña-larga-aleatoria"
ip: 10.10.10.100/24

Los nodos detrás de NAT se conectan al servidor en la nube, se enteran unos de otros e intentan establecer una conexión directa. Si cambia la dirección del punto de conexión, usa un nombre DNS o el mecanismo beacon.

Escenario 3: acceso a una subred detrás de un nodo

El servidor en la nube atiende la subred interna 192.168.50.0/24; el equipo doméstico debe acceder a ella. En modo tun el nodo anuncia la subred mediante claims, y la dirección de la interfaz se establece con una máscara más amplia para que todas las subredes VPN sean alcanzables a través de él (así lo recomienda la documentación de VPNCloud):

# servidor en la nube
listen: 3210
peers: []
crypto:
  password: "contraseña-larga-aleatoria"
ip: 10.10.10.30/16
claims:
  - 192.168.50.0/24

En el servidor en la nube hay que habilitar el reenvío de paquetes y permitirlo en el cortafuegos:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpncloud.conf
sudo sysctl --system
sudo iptables -A FORWARD -i vpncloud0 -o eth0 -d 192.168.50.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o vpncloud0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

En el equipo doméstico: ruta a la subred a través de la interfaz VPN:

sudo ip route add 192.168.50.0/24 dev vpncloud0

Si los dispositivos de la subred 192.168.50.0/24 no conocen la ruta de retorno hacia la red VPN, añádela en su puerta de enlace o activa el enmascaramiento en el servidor en la nube para el tráfico desde la VPN (iptables -t nat -A POSTROUTING -s 10.10.0.0/16 -d 192.168.50.0/24 -j MASQUERADE).

Recomendaciones

• Contraseña de la red — larga y aleatoria; para requisitos estrictos use claves en lugar de la contraseña.
• La subred VPN no debe solaparse con las redes locales de los nodos.
• Varios puntos de conexión en peers aumentan la tolerancia a fallos si uno de ellos no está disponible.
• rp_filter. Al enrutar subredes, la comprobación estricta de la ruta inversa puede descartar paquetes; VPNCloud tiene el parámetro device.fix-rp-filter, más información sobre el mecanismo en el artículo sobre rp_filter.
• Elección de cara al futuro. Como el proyecto no se desarrolla, no cabe esperar correcciones de vulnerabilidades. Para redes nuevas, use soluciones mantenidas de la serie Mesh VPN.