WireGuard Mesh Networking: cómo crear una red Zero Trust entre servidores y NAS con Tailscale y Netmaker

Guía práctica para construir una red en malla Zero Trust entre servidores remotos y un NAS con WireGuard, con dos caminos concretos: Tailscale (SaaS) y Netmaker (autoalojado).

Nov 6, 2026 0 3

WireGuard Mesh Networking: cómo crear una red Zero Trust entre servidores y NAS con Tailscale y Netmaker

Conectar dos servidores con una VPN punto a punto basada en WireGuard se configura en pocos minutos. El problema empieza cuando el número de nodos crece a cinco, diez, veinte: servidores en la nube repartidos entre distintos proveedores, un NAS en la oficina, algunas Raspberry Pi y los portátiles del equipo. Configurar a mano cada par de peers se convierte rápidamente en una pesadilla de claves públicas, direcciones IP y archivos de configuración que hay que actualizar manualmente con cada cambio.

Aquí entra en juego el concepto de mesh networking (red en malla): una red en la que cada dispositivo puede hablar directamente con cualquier otro dispositivo autorizado, sin pasar por un único punto central, y en la que el acceso no depende de "estar dentro del perímetro de la empresa" sino de reglas explícitas verificadas en cada conexión. Este segundo principio tiene un nombre: Zero Trust. En esta guía veremos cómo construir en la práctica una malla Zero Trust entre servidores remotos y un NAS, usando WireGuard como base criptográfica y dos herramientas que lo orquestan de forma muy distinta: Tailscale (servicio SaaS) y Netmaker (autoalojado).

WireGuard en pocas palabras: por qué se convirtió en el estándar

WireGuard es un protocolo VPN moderno, pensado para ser fácil de auditar (su código fuente es órdenes de magnitud más pequeño que el de OpenVPN o IPsec) y rápido, ya que se ejecuta directamente dentro del kernel de Linux desde la versión 5.6. Utiliza algoritmos criptográficos modernos como Curve25519 para el intercambio de claves y ChaCha20 para el cifrado del tráfico, e identifica cada dispositivo mediante un par de claves pública/privada en lugar de nombre de usuario y contraseña.

El límite de WireGuard "puro" no es la seguridad, sino la organización: por defecto está pensado para enlaces punto a punto. Construir una malla con muchos nodos implica generar y distribuir manualmente las claves de cada peer al resto, actualizar las direcciones AllowedIPs con cada cambio y llevar el control de todo a mano. Eso es exactamente lo que automatizan Tailscale y Netmaker: ambos usan el protocolo WireGuard por debajo, pero añaden una capa de orquestación automática (distribución de claves, descubrimiento de peers, reglas de acceso) que lo hace manejable incluso con decenas de nodos.

El principio Zero Trust aplicado a la red

El modelo de seguridad de red tradicional se basa en un perímetro: si un dispositivo está "dentro" (en la oficina, en la VPN corporativa), se confía en él casi por completo. El problema es que, una vez superado ese perímetro - una credencial robada, un portátil comprometido -, un atacante tiene vía libre para moverse lateralmente entre los sistemas.

El principio Zero Trust invierte ese enfoque: ningún dispositivo ni usuario se considera automáticamente fiable, ni siquiera los que ya están "dentro" de la red. Cada conexión se autentica y autoriza de forma individual, siguiendo el principio de mínimo privilegio: un servidor de copias de seguridad solo debería poder alcanzar el NAS en el que escribe, no la base de datos de producción ni el puesto del administrador. Aplicado a una malla WireGuard, esto se traduce en la práctica en dos cosas: una identidad fuerte para cada nodo (la clave pública de WireGuard, única por dispositivo) y un sistema de reglas (una ACL, lista de control de acceso) que decide explícitamente quién puede hablar con quién, en lugar de dejar que "cualquiera que esté en la red" lo alcance todo.

Tailscale y Netmaker: dos filosofías distintas

Tanto Tailscale como Netmaker construyen una malla WireGuard automatizada, pero parten de premisas opuestas. Tailscale es un servicio SaaS: el plano de control (autenticación, distribución de claves, interfaz de gestión) lo gestionan los servidores de Tailscale, mientras que el tráfico entre dispositivos viaja directamente de igual a igual (peer-to-peer) cuando es posible. Netmaker, en cambio, está pensado para ser autoalojado: se instala el plano de control (la Community Edition, gratuita y de código abierto) en el propio servidor, y se sigue siendo propietario de toda la infraestructura, incluidos los datos.

Esta diferencia también se refleja en los precios. Tailscale tiene un plan "Personal" gratuito para uso no comercial, hasta 6 usuarios con dispositivos ilimitados; los planes de equipo empiezan en 8 dólares por usuario al mes (plan Standard), hasta los 18 dólares del plan Premium pensado para organizaciones más grandes. Netmaker, por su parte, ofrece una Community Edition gratuita y de código abierto sin límites declarados de dispositivos o redes, con planes de pago (Team y Business) calculados por conexión activa, desde aproximadamente 2 dólares por conexión al mes, pensados para quienes quieren funciones adicionales como la conmutación por error automática o una gestión de usuarios más avanzada.

En términos prácticos: si se quiere empezar de inmediato sin gestionar un servidor adicional, y no hay inconveniente en confiar el plano de control a un proveedor externo, Tailscale es la opción más rápida. Si en cambio la prioridad es mantener toda la infraestructura - incluido el servidor que decide "quién habla con quién" - bajo el propio control, Netmaker es la opción a considerar, al precio de tener que gestionar un servidor más.

Primera vía: una malla Zero Trust con Tailscale

Tailscale se instala en cada dispositivo que debe formar parte de la red (servidores, portátiles, Raspberry Pi) mediante un cliente ligero. Una vez autenticados, los dispositivos obtienen una dirección IP virtual estable dentro del rango privado 100.64.0.0/10 (el mismo rango usado para CGNAT) y pueden alcanzarse entre sí directamente.

Exponer un NAS sin instalar nada en él

Muchos NAS no admiten instalar directamente un cliente de Tailscale, o se prefiere no tocar el sistema del fabricante. La solución es el patrón del subnet router (enrutador de subred): se instala Tailscale en un dispositivo siempre encendido en la misma red local que el NAS (por ejemplo, un pequeño servidor Linux o una Raspberry Pi), y este actúa como "puente" para exponer toda la subred a la malla, sin que el propio NAS necesite saber nada de WireGuard ni de Tailscale.

En el dispositivo puente, tras habilitar el reenvío de IP a nivel de sistema, se arranca el cliente con:

tailscale up --advertise-routes=192.168.1.0/24

donde 192.168.1.0/24 es la subred local en la que se encuentra el NAS. Este paso por sí solo no basta: la ruta anunciada debe ser aprobada por un administrador en la consola web de gestión (sección "Machines", dispositivo con la etiqueta "Subnets"), a menos que ya esté cubierta por una regla autoApprovers en el archivo de política. Solo entonces los demás nodos de la malla, si están configurados para aceptar rutas con tailscale set --accept-routes (comportamiento automático en macOS, iOS, Android y Windows), pueden alcanzar el NAS en su dirección IP local original, como si estuvieran en la misma LAN.

Escribir las reglas de acceso (ACL/grants)

Por defecto, una "tailnet" recién creada (así se llama la red privada de Tailscale) permite que todos los dispositivos se alcancen entre sí: todo está permitido salvo las reglas explícitas. Para aplicar de verdad el principio Zero Trust hay que invertir esa lógica, eliminando la regla permisiva por defecto y escribiendo solo los permisos necesarios en el archivo de política, en formato JSON. La sintaxis moderna se llama grants (preferida frente al formato más antiguo acls, aunque ambos pueden coexistir), y cada regla especifica un origen, un destino y los puertos permitidos:

{
  "hosts": {
    "backup-server": "100.64.0.10",
    "nas": "100.64.0.20"
  },
  "grants": [
    {
      "src": ["backup-server"],
      "dst": ["nas"],
      "ip": ["tcp:445", "tcp:22"]
    }
  ]
}

En este ejemplo, solo el servidor de copias de seguridad puede alcanzar el NAS, y únicamente por los puertos SMB (445) y SSH (22): ningún otro dispositivo de la malla, ni siquiera uno con acceso completo a otros sistemas, puede tocarlo. Para organizar los permisos entre varios dispositivos se pueden usar etiquetas (tags), asignadas en la sección tagOwners de la política: una etiqueta traslada la "propiedad" del dispositivo de una cuenta humana individual a la propia etiqueta, de modo que el acceso ya no depende de quién inició sesión originalmente en esa máquina. Un detalle práctico nada trivial: quitar una etiqueta de un dispositivo no es sencillo - a menudo requiere eliminar el nodo de la red y volver a registrarlo desde cero -, así que conviene planificar con cuidado el esquema de etiquetas antes de llevarlo a producción.

Acceso SSH sin claves que gestionar

Una ventaja práctica de apoyarse en la identidad de Tailscale para toda la red es poder habilitar el acceso SSH "sin claves": al activarlo en un servidor con tailscale set --ssh, la autenticación SSH se basa en la identidad de la tailnet en lugar de en claves que haya que generar, distribuir y revocar manualmente. Las reglas sobre quién puede acceder por SSH, y con qué usuario del sistema, se definen en un bloque independiente de la política:

{
  "ssh": [
    {
      "action": "check",
      "src": ["group:sysadmin"],
      "dst": ["tag:server"],
      "users": ["deploy"]
    }
  ]
}

Con "action": "check", el acceso exige una reautenticación periódica (el intervalo se define con checkPeriod), útil en los servidores más sensibles; con "action": "accept", el acceso se concede de inmediato una vez verificada la identidad. En ambos casos, la configuración SSH del propio sistema operativo debe seguir autorizando a ese usuario concreto.

Dos advertencias prácticas antes de pasar a producción: las claves de los nodos caducan por defecto a los 180 días, lo que puede desconectar silenciosamente un subnet router o un exit node si no se desactiva la caducidad en los dispositivos que cumplen un papel de infraestructura permanente; y los cambios en la política se aplican de inmediato al guardarlos, por lo que una regla demasiado restrictiva puede cortar la propia sesión SSH con la que se está trabajando - siempre conviene revisar el diff de los cambios antes de confirmarlos.

Segunda vía: una malla autoalojada con Netmaker

Si la prioridad es mantener el control total de la infraestructura, Netmaker Community Edition permite instalar el propio plano de control en un servidor, sin depender de un proveedor externo para decidir quién puede acceder a qué.

Requisitos e instalación

Para la Community Edition, Netmaker requiere un servidor Ubuntu 24.04 (puede ser una VM, hardware físico o incluso la misma máquina en la que corren los demás servicios), con un mínimo de 1 GB de RAM, 1 CPU y 2 GB de almacenamiento para pruebas, pero al menos 2 GB de RAM y 2 CPU para un uso en producción. Se necesita una dirección IP pública estática y, idealmente, un nombre de dominio con acceso a la gestión DNS, porque el panel, la API, el broker MQTT y las herramientas de monitorización (Prometheus, Grafana) necesitan cada uno su propio subdominio público (o un comodín como *.netmaker.ejemplo.es). Hay que abrir los puertos 80/TCP y 443/TCP para los certificados y la interfaz web, y el puerto 51821/UDP para el tráfico WireGuard del agente.

La instalación guiada de la Community Edition se reduce a descargar y ejecutar el script oficial desde el repositorio de GitHub de Netmaker:

curl -sfL https://raw.githubusercontent.com/gravitl/netmaker/master/scripts/nm-quick.sh -o /root/nm-quick.sh
chmod +x /root/nm-quick.sh
sudo /root/nm-quick.sh

El script configura automáticamente los certificados TLS (mediante Caddy), el broker MQTT usado para la comunicación con los clientes y el panel de administración. Un aviso útil para quienes usan Cloudflare como proxy DNS: hay que desactivar el proxy ("nube gris" en lugar de naranja) en los registros usados por Netmaker, porque de lo contrario el tráfico MQTT se bloquea de una forma que el propio Netmaker no puede diagnosticar.

Crear la red y añadir nodos

En el primer acceso al panel se crea una cuenta de administrador, y después se crea una nueva red eligiendo un rango de direcciones privadas que no se superponga con otras redes ya en uso (para redes de menos de 254 máquinas, un bloque como 10.11.12.0/24 es más que suficiente). El servidor Netmaker se añade automáticamente a la red como primer nodo.

Para añadir un servidor remoto o el dispositivo puente hacia el NAS, se genera desde el panel una enrollment key (sección "Keys"), definiendo cuántas veces puede usarse y a qué redes da acceso. En el nuevo host, tras comprobar que WireGuard y systemd están instalados, se instala el netclient para el sistema operativo correspondiente y se registra el nodo con:

netclient register -k  -s grpc.midominio.es -p 50051

Poco después el nodo aparece en el panel de administración, y se puede comprobar la conectividad con un simple ping a su dirección privada dentro de la malla desde otro nodo ya conectado. Para los nodos que se añaden más adelante a una red ya existente, se puede usar en su lugar un token de registro específico pensado exactamente para ese caso.

Netmaker gestiona la seguridad de la malla mediante ACL a nivel de red (qué nodos de una misma red virtual pueden hablar entre sí) y etiquetas asignables a las claves de enrolamiento, un mecanismo distinto, pero conceptualmente afín a los grants de Tailscale: también aquí el objetivo es evitar que "formar parte de la malla" equivalga automáticamente a "tener acceso a todo".

Buenas prácticas de seguridad, sea cual sea la herramienta elegida

Independientemente de la vía elegida, algunas precauciones valen para ambas. Primero: desactivar la caducidad automática de las claves en los dispositivos que cumplen un papel de infraestructura permanente, como el subnet router que expone el NAS o el propio servidor Netmaker - una clave caducada sin previo aviso en un nodo crítico significa una interrupción de servicio silenciosa. Segundo: aplicar siempre el principio de mínimo privilegio al escribir las reglas de acceso, concediendo a cada nodo solo los puertos y peers que realmente necesita, y no "todo lo necesario más un poco por si acaso" - que es exactamente lo contrario del espíritu Zero Trust. Tercero: mantener actualizados tanto el cliente WireGuard subyacente como el software de orquestación (Tailscale o el netclient de Netmaker), ya que ambos reciben periódicamente parches de seguridad. Cuarto, y a menudo subestimado: probar las reglas de acceso antes de confiar en ellas en producción, comprobando no solo que las conexiones autorizadas funcionan, sino también que las no autorizadas quedan efectivamente bloqueadas.

¿Cuál elegir?

No hay una respuesta universal, pero sí algunas indicaciones prácticas. Para un homelab, un equipo pequeño o quien quiera empezar de inmediato sin administrar un servidor adicional, Tailscale ofrece el camino más rápido, un plan gratuito generoso para uso personal y una gestión de políticas lo bastante granular como para implementar un verdadero modelo Zero Trust. Para quienes ya gestionan su propia infraestructura de servidores, tienen requisitos de cumplimiento que exigen mantener los datos y el plano de control en sus propias instalaciones, o simplemente prefieren no depender de un proveedor SaaS externo para algo tan crítico como el acceso a la red, Netmaker Community Edition ofrece las mismas garantías de seguridad basadas en WireGuard, al precio de un servidor más que administrar y mantener actualizado. En ambos casos, el resultado final es el mismo: una malla cifrada, rápida por estar basada en WireGuard, y diseñada según el principio de que ninguna conexión se concede por defecto, sino solo porque ha sido autorizada explícitamente.