WireGuard para IoT: securing dispositivos embebidos en 2026

WireGuard se volvió el estándar de facto para VPNs en dispositivos IoT y embebidos. Su diseño minimalista (menos de 4.000 líneas de código) y su footprint bajo lo hacen ideal para correr en routers, Raspberry Pis, gateways industriales y SBCs. Esta guía te muestra cómo desplegarlo en un dispositivo embebido, qué trade-offs enfrentar y cuándo elegirlo sobre Tailscale o alternativas pesadas como OpenVPN.

El escenario típico: tienes 10-50 dispositivos distribuidos (sensores, gateways, routers) que necesitan comunicarse entre sí o con un servidor central, pero no quieres mantener una VPN pesada con OpenVPN o IPSec. WireGuard te da cifrado moderno, latencia baja y configuración simple que cabe en un script.

Por qué WireGuard en IoT específicamente

Las VPNs tradicionales (OpenVPN, IPSec) tienen tres problemas serios en hardware embebido:

• CPU usage alto: OpenVPN en userspace pasa por el kernel dos veces (entrada y salida). En un ESP32 o un ARM Cortex-A53, esto se nota inmediatamente.
• Memoria footprint: OpenVPN carga toda la TLS stack en RAM. Un router con 64 MB de RAM queda apretado si también corre otras cosas.
• Configuración compleja: certificados, DH params, configuración TLS, renegociación. Para 30 dispositivos tienes un script grande de bootstrap.

WireGuard resuelve los tres:

• Kernel-space en Linux: corre en el kernel como cualquier NIC virtual. El overhead es prácticamente cero para paquetes pequeños.
• Footprint diminuto: ~30 KB de binario, sin state persistente por conexión.
• Config estática: clave privada, clave pública del peer, endpoint. Tres líneas y funciona.

Para un sensor industrial que envía 100 bytes cada 5 minutos, WireGuard consume 0.1% CPU. OpenVPN consumiría 3-5%. La diferencia es energía en dispositivos a batería.

Arquitectura de despliegue típica

Lo más común para deployments de IoT es topología hub-and-spoke: un servidor central (hub) acepta conexiones de N dispositivos (spokes) y rutea tráfico entre ellos. Para más de 20 dispositivos, pasás a mesh completo o usas un plano de control como Tailscale/Headscale.

Componentes mínimos:

• Servidor WireGuard: VPS o servidor dedicado con IP pública fija. Maneja la configuración de los peers.
• Dispositivos IoT: cada uno con su par de claves WireGuard (privada/pública).
• Mecanismo de distribución de configs: SSH al servidor, API REST, Ansible, o un script de bootstrap.

Setup del servidor WireGuard

Asumimos Debian 12 / Ubuntu 24.04. El proceso es similar en otras distros.

1. Instalar y generar claves del servidor

sudo apt update
sudo apt install wireguard -y
# Generar claves del servidor
cd /etc/wireguard
umask 077
wg genkey | tee server_private.key | wg pubkey > server_public.key
chmod 600 server_private.key
# Anotar las claves (las necesitamos para la config)
cat server_private.key
cat server_public.key

2. Configurar la interfaz WireGuard

El archivo de configuración principal es /etc/wireguard/wg0.conf. Para un hub central con NAT traversal:

[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = <contenido de server_private.key>
# Habilitar IP forwarding y NAT para tráfico de los peers
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
# Los peers se agregan con wg set o directamente en este archivo

3. Habilitar IP forwarding

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

4. Iniciar la interfaz

sudo systemctl enable --now wg-quick@wg0
sudo wg show

El último comando muestra la interfaz wg0 con su clave pública y puerto de escucha.

Agregar dispositivos IoT

Para cada dispositivo nuevo, generas un par de claves en el dispositivo mismo, agregas su clave pública al servidor, y le das al dispositivo la clave pública del servidor + endpoint. El flujo seguro es generar las claves en el dispositivo (no transferirlas por la red).

Generar claves en el dispositivo

Si el dispositivo tiene wg instalado (generalmente sí en OpenWrt, Raspbian, Ubuntu Core):

# En el dispositivo IoT
wg genkey | tee device_private.key | wg pubkey > device_public.key
cat device_public.key  # Esta clave se la pasamos al admin del servidor

Si el dispositivo no tiene wg (algunos embedded Linux no lo incluyen), generas las claves en una máquina más poderosa y las transferís por canal seguro (SSH, scp).

Registrar el peer en el servidor

# En el servidor, agregar peer temporalmente
sudo wg set wg0 peer <device_public_key> allowed-ips 10.100.0.42/32
# Para que persista, agregar al wg0.conf
sudo wg-quick save wg0

Configurar el dispositivo IoT

[Interface]
Address = 10.100.0.42/24
PrivateKey = <contenido de device_private.key>
[Peer]
PublicKey = <contenido de server_public.key>
Endpoint = <ip_publica_del_servidor>:51820
AllowedIPs = 10.100.0.0/24
PersistentKeepalive = 25

PersistentKeepalive = 25 es crítico en IoT: dispositivos detrás de NAT necesitan enviar un paquete cada 25 segundos para mantener el mapeo de puerto abierto. Sin esto, después de 3-5 minutos de inactividad el túnel se cae.

Bootstrap automatizado con Ansible

Para deployments grandes (más de 20 dispositivos), quieres automatizar. Ansible es la herramienta más práctica:

# playbook.yml
---
- name: Configure WireGuard on IoT devices
  hosts: iot_devices
  become: true
  tasks:
    - name: Install WireGuard
      apt:
        name: wireguard
        state: present
      when: ansible_os_family == "Debian"
    - name: Generate device keys
      shell: |
        cd /etc/wireguard
        umask 077
        wg genkey | tee device_private.key | wg pubkey > device_public.key
        chmod 600 device_private.key
      args:
        creates: /etc/wireguard/device_private.key
    - name: Fetch device public key
      fetch:
        src: /etc/wireguard/device_public.key
        dest: "keys/{{ inventory_hostname }}.pub"
        flat: yes
    - name: Deploy WireGuard config
      template:
        src: wg0.conf.j2
        dest: /etc/wireguard/wg0.conf
        mode: 0600
      notify: restart wireguard
  handlers:
    - name: restart wireguard
      service:
        name: wg-quick@wg0
        state: restarted

Casos de uso reales en producción

Monitoreo industrial (SCADA)

Plantas con PLCs y gateways industriales a menudo necesitan conectividad segura entre sitios. WireGuard sobre 4G o satélite es viable en lugares donde no llega cable. La latencia baja de WireGuard (más cercana a la red que a la VPN) es crítica cuando manejás control en tiempo real.

Sensores remotos con telemetría

Sensores LoRaWAN con gateways LTE necesitan reportar a un servidor central. WireGuard sobre el mismo modem LTE te da cifrado E2E sin agregar latencia significativa. Comparado con HTTPS sobre la misma conexión, ahorra ~30% CPU en el gateway.

Home Assistant y domótica

Si tienes Home Assistant en una Raspberry Pi y quieres acceder desde afuera, WireGuard en el router de casa es la solución más limpia. Alternativas como Tailscale funcionan pero agregan dependencia de un SaaS externo que no necesitas para esto.

Edge computing en retail

Cadenas de tiendas con 50-500 locales necesitan conectividad entre cajas registradoras, inventario y un servidor central. WireGuard en cada local con un hub centralizado es más simple que mantener una PKI completa con OpenVPN.

Limitaciones que tienes que conocer

Sin roaming nativo

Si un dispositivo cambia de IP (WiFi a 4G, por ejemplo), WireGuard tiene que renegociar el endpoint. Con PersistentKeepalive el túnel se recupera en ~30 segundos, pero hay un breve período sin conectividad. Para aplicaciones que no toleran esto, hace falta un mecanismo de reconexión más agresivo (cron cada 10 segundos que verifica el endpoint).

Sin NAT traversal automático

Si dos dispositivos IoT están detrás de NAT y quieren comunicarse directamente, WireGuard no los ayuda. La solución típica es enrutar todo el tráfico a través del hub. Tailscale y NetBird resuelven esto con relays DERP/STUN, pero a costa de más complejidad.

Curva de aprendizaje de keys

Administrar pares de claves para 50 dispositivos requiere disciplina. Sin un sistema de tracking (qué dispositivo tiene qué clave, qué IP interna, cuándo se agregó), terminás con claves huérfanas y problemas de auditoría. usa Ansible o un script versionado para evitar esto.

Cuándo NO usar WireGuard en IoT

• Dispositivos que no pueden correr código custom: appliances con firmware cerrado que no soportan WireGuard. Acá no hay opción.
• Necesidad de NAT traversal automático sin hub: si los dispositivos IoT necesitan hablar entre sí sin pasar por un servidor central, Tailscale o NetBird resuelven mejor.
• Compliance que requiere TLS explícito: algunos regulators (PCI-DSS, HIPAA) requieren TLS 1.3 con cert pinning. WireGuard no es TLS, es IPsec-style. Para eso, OpenVPN sigue siendo la opción.

Monitoreo y troubleshooting

En el servidor, el comando principal es:

sudo wg show

Esto muestra cada peer con: clave pública, endpoint actual, último handshake, bytes transferidos. Si el último handshake es muy viejo, el peer no se está conectando.

Para métricas más detalladas, configura Prometheus node_exporter con wireguard_exporter. El dashboard Grafana típico muestra:

• Bytes transferidos por peer.
• Latencia de handshake.
• Número de peers activos vs inactivos.
• Tiempo desde el último handshake.

Si un peer no aparece, los pasos de diagnóstico:

# 1. Verificar que la interfaz está arriba en el servidor
ip link show wg0
# 2. Verificar que el puerto está escuchando
sudo ss -ulpn | grep 51820
# 3. Verificar que el peer agregó correctamente
sudo wg show wg0 latest-handshakes
# 4. Verificar que el firewall permite UDP 51820
sudo iptables -L INPUT -n | grep 51820

Resumen

WireGuard es la opción correcta para VPNs en IoT cuando necesitas:

• Cifrado moderno con footprint bajo.
• Latencia baja en hardware limitado.
• Configuración simple que escala a 50+ dispositivos con Ansible.
• Topología hub-and-spoke con el servidor central.

Si necesitas NAT traversal automático entre dispositivos o compliance con TLS explícito, mira Tailscale (con overhead) o OpenVPN (con footprint). Para el resto, WireGuard es la respuesta en 2026.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux