Redes

Configura Wireguard en tu teléfono: Accede a todo desde cualquier lugar

WireGuard no es solo para unir dos servidores: es la opción más ligera, rápida y auditable para llevar tu infraestructura contigo en el teléfono. Cuando lo configuras correctamente, accedes a tus servicios internos, bases de datos, NAS y dashboards desde cualquier red móvil sin abrir puertos al público ni depender de proveedores SaaS. Esta guía recorre el flujo completo: preparar el servidor, generar las claves, exportar el archivo para Android o iOS y verificar que el túnel cifrado funciona antes de salir de tu red.

TL;DR — Lo que vas a tener al final

  • Tiempo de setup: 25-45 minutos para P2P, 1-2 horas para hub-and-spoke.
  • Requisitos: Linux con kernel 5.6+, root, IP pública (o PersistentKeepalive).
  • Resultado: Túnel cifrado Curve25519/AES-256/Chacha20 con baja latencia.
  • Troubleshooting: UDP bloqueado, AllowedIPs mal escrita, `wg show` y `tcpdump` son tus amigos.

Por qué WireGuard en tu teléfono y no otra opción

El teléfono rara vez usa la misma red Wi-Fi que tu servidor durante más de unas horas al día. Si necesitas llegar a una base de datos, al panel de Home Assistant o al syncthing de tu NAS, las opciones comerciales como Tailscale, ZeroTier o NetBird resuelven el problema con menos fricción, pero añaden un servidor de coordinación externo y términos de servicio que cambian sin avisar. WireGuard puro deja el control 100% en tu servidor: tú decides quién se conecta, con qué clave y durante cuánto tiempo.

La otra ventaja es técnica. El código de WireGuard ocupa menos de 4.000 líneas y está auditado por Academia y empresa desde su inclusión en el kernel Linux 5.6 en marzo de 2020. El handshake inicial apenas transmite 1.400 bytes, así que en redes móviles con pérdida de paquetes entabla conexión rápido y reanuda sin renegociar cuando cambias de LTE a Wi-Fi. Para una Raspberry Pi, una nube en Hetzner o un homelab con IP pública, levantar el servidor lleva menos de diez minutos.

Lo que necesitas antes de empezar

El servidor debe ser una máquina Linux con una IP pública fija o casi fija (Hetzner, OVH, DigitalOcean, una conexión de fibra en casa con DDNS, o una VPS de bajo costo). La distribución puede ser Debian 12+, Ubuntu 22.04+, Fedora 40+ o RHEL 9+; el módulo wireguard ya viene incluido en el kernel. El teléfono puede ser Android 8+ o iOS 12+; las apps oficiales son de código abierto y se descargan desde Google Play, App Store o F-Droid.

Antes de continuar confirma tres cosas: que tienes acceso root en el servidor (o capacidad sudo), que el puerto UDP 51820 está libre y que tu proveedor de Internet no bloquea ese puerto (algunos carriers corporativos sí; las redes domésticas rara vez lo hacen). Si tu servidor está detrás de un NAT, redirige ese puerto UDP en el router hacia la IP privada del servidor. Más adelante verás qué abrir y qué no.

Generar claves pública y privada

WireGuard usa criptografía de curva elíptica Curve25519 para los pares de claves. Generar el par en el servidor es directo con wg genkey y wg pubkey. Crea un directorio dedicado para que los archivos no se mezclen con otras configuraciones.

# En el servidor como root
mkdir -p /etc/wireguard/clients
cd /etc/wireguard
# Clave privada del servidor (guardar de forma segura)
wg genkey | tee server_private.key | wg pubkey > server_public.key
chmod 600 server_private.key
ls -l server_private.key server_public.key

El comando wg genkey produce 44 caracteres base64; wg pubkey deriva la pública a partir de la privada. La clave privada NUNCA debe salir del servidor. Si la publicas por error, regenera el par completo y reaplica las configuraciones de los clientes. La pública se comparte con cada peer: el teléfono guarda la pública del servidor y el servidor guarda la pública del teléfono.

Si tu distribución no trae wg (Fedora, RHEL, algunos contenedores), instala el paquete wireguard-tools. En Debian/Ubuntu ya viene con wireguard. El módulo del kernel se compila bajo demanda la primera vez; si no carga, ejecuta modprobe wireguard y verifica con lsmod | grep wireguard.

Levantar la interfaz wg0 en el servidor

Crea el archivo /etc/wireguard/wg0.conf con los parámetros del túnel: dirección IP de la interfaz virtual, puerto de escucha y la clave privada. Más abajo añadirás los peers (el teléfono) en el mismo archivo.

cat > /etc/wireguard/wg0.conf <<'EOF'
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = $(cat /etc/wireguard/server_private.key)
PostUp = nft -f /etc/wireguard/nftables.conf
PostDown = nft delete table inet wireguard
EOF
chmod 600 /etc/wireguard/wg0.conf

La dirección 10.10.0.1/24 es la IP del servidor dentro del túnel; los clientes recibirán direcciones del rango 10.10.0.0/24. PostUp y PostDown aplican reglas de firewall cuando la interfaz sube o baja; las verás en la siguiente sección. Para arrancar la interfaz manualmente usa wg-quick up wg0; para dejarlo persistente entre reinicios, habilita el servicio systemd systemctl enable --now [email protected].

Habilitar reenvío IP y NAT

Para que el teléfono llegue a tu red interna, el servidor necesita reenviar tráfico entre la interfaz wg0 y la interfaz WAN (eth0, ens3 o similar). Sin reenvío IP los paquetes llegan al servidor pero no salen. Sin NAT, los hosts internos no saben a quién responder.

Primero, activa el reenvío IP en el kernel de forma persistente:

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/99-wireguard.conf
sysctl -p /etc/sysctl.d/99-wireguard.conf
sysctl net.ipv4.ip_forward

El valor debe devolver 1. Si tu servidor usa nftables, crea /etc/wireguard/nftables.conf con la regla de NAT. La tabla detecta la interfaz WAN automáticamente y la renombra al cargarse, así que el archivo es portable.

cat > /etc/wireguard/nftables.conf <<'EOF'
table inet wireguard {
    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
    }
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname "eth0" ip saddr 10.10.0.0/24 masquerade
        oifname "ens3" ip saddr 10.10.0.0/24 masquerade
        oifname "enp0s3" ip saddr 10.10.0.0/24 masquerade
    }
}
EOF

Si usas iptables clásico, la regla equivalente es iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -o eth0 -j MASQUERADE. Verifica con iptables -t nat -L POSTROUTING -n -v que aparece aplicada. En hosts con firewalld (Fedora, RHEL) necesitas firewall-cmd --permanent --zone=public --add-masquerade antes del reload.

Crear la configuración para el teléfono

Cada cliente necesita su propio par de claves y un archivo .conf que se importa en la app oficial. Genera el par del teléfono en un paso, añade el peer al servidor y construye el archivo del cliente.

# Par de claves del teléfono
wg genkey | tee client1_private.key | wg pubkey > client1_public.key
chmod 600 client1_private.key
# Datos que iran en el .conf del telefono
CLIENT_PRIV=$(cat client1_private.key)
CLIENT_PUB=$(cat client1_public.key)
SERVER_PUB=$(cat server_public.key)

Ahora añade el peer del teléfono al wg0.conf del servidor. Edita el archivo y agrega el bloque [Peer] justo debajo del bloque [Interface] existente.

cat >> /etc/wireguard/wg0.conf <

AllowedIPs dentro del servidor controla qué IPs del túnel se le asignan al peer Y qué tráfico pasa por él. 10.10.0.2/32 significa que este cliente solo enruta sus propios paquetes por el túnel (no los de otros peers). En el archivo del cliente verás que esa misma línea controla qué tráfico del teléfono se envía al servidor: 0.0.0.0/0 envía todo (full-tunnel) y 10.10.0.0/24, 192.168.1.0/24 solo lo interno (split-tunnel).

Genera el archivo del teléfono con permisos seguros. NO hagas esto sobre SSH a un equipo del que no confías el archivo temporal; lo ideal es SCPearlo a tu máquina local primero.

cat > /tmp/phone1.conf <

DNS = 10.10.0.1, 1.1.1.1 indica al teléfono que use primero tu servidor DNS interno y como fallback el DNS público de Cloudflare. Si tu servidor no corre un DNS propio, omite la primera IP y deja solo el fallback. PersistentKeepalive = 25 envía un paquete vacío cada 25 segundos; en redes móviles ayuda a mantener el NAT abierto y a que el handshake se mantenga vivo.

Instalar la app de WireGuard en el móvil

La aplicación oficial está publicada por el equipo de WireGuard y el código fuente es público en GitHub (zx2c4/wireguard-android y zx2c4/wireguard-apple). En Android la encuentras como "WireGuard" en Google Play o como paquete F-Droid; en iOS se llama igual en la App Store. Ambas soportan importación de archivos .conf, QR y túnel por aplicación.

Transfiere el archivo phone1.conf al teléfono. Tres opciones que suelo recomendar: (1) qrencode -t ansiutf8 < /tmp/phone1.conf en el servidor y escanear el QR desde la app (la app genera el QR al tocar "Crear desde QR"); (2) copiar el archivo a Nextcloud o a un servicio propio y descargarlo; (3) enviarlo por SSH al móvil usando apps como Termux y reenviarlo a WireGuard via "Abrir con". Evita subirlo a Drive, iCloud o Dropbox sin cifrar; la clave privada del cliente está dentro.

Probar la conexión y verificar el túnel

Antes de salir de tu red Wi-Fi, abre la app en el teléfono, activa el túnel y verifica que hay tráfico. Empieza por confirmar handshake en el servidor.

# En el servidor
wg show

Verás un bloque por peer con su clave pública, endpoint (IP:puerto desde la que se conectó), última vez que se vio un handshake válido y bytes transferidos. Una línea con latest handshake: 12 seconds ago confirma que el túnel está vivo. Si dice never, el cliente no llegó al servidor: revisa el puerto, el firewall y la regla de NAT del router.

Después, desde el teléfono, abre una app de pruebas (la propia app de WireGuard muestra el log de handshake) y comprueba que navegas a Internet. Para validar el split-tunnel, visita una página como https://ifconfig.me: la IP que devuelve debe ser la pública de tu servidor, no la del operador móvil. Si el teléfono está conectado al Wi-Fi de tu casa, esa misma IP es la pública del servidor; cuando sales y usas 4G, sigue siendo la del servidor, confirmando que todo el tráfico pasa por el túnel.

Casos de uso: acceder a servicios internos

Con el túnel activo, el teléfono obtiene una IP 10.10.0.2 con acceso a toda tu red interna. Los casos que suelo ver en homelabs y sysadmins LATAM:

  • NAS y archivos: entrar a Synology/QNAP vía https://10.10.0.1:5001 o por SMB si configuraste el reenvío, sin abrir esos puertos a Internet.
  • Home Assistant y domótica: acceder al panel local desde fuera de casa y disparar automatizaciones remotamente.
  • Infraestructura Kubernetes/Docker: alcanzar el dashboard de Portainer, Grafana o ArgoCD sin VPN corporativo.
  • SSH a servidores internos: aunque SSH debería limitarse por IP, el túnel permite hacer ssh 192.168.1.50 desde el teléfono como si estuvieras en casa.
  • Sincronización P2P: Syncthing y otros clientes funcionan sobre el túnel sin necesidad de relay público.

Para que estos servicios sean alcanzables, el servidor WireGuard debe tener una ruta a la red interna (192.168.1.0/24 en el ejemplo) y el AllowedIPs del cliente debe incluir esa subred. Si el servidor WireGuard no es el gateway de la red interna, añade una ruta estática en ese gateway para que 10.10.0.0/24 se devuelva al servidor WireGuard.

Seguridad: rotación de claves y firewalls

Las claves de WireGuard no caducan por sí solas. Mientras el par siga registrado en wg0.conf y el cliente conserve el archivo .conf, la conexión es válida. Esta propiedad es cómoda pero un riesgo si el teléfono se pierde o se renueva: la clave privada sigue siendo usable.

Buenas prácticas que vale la pena implementar desde el día uno:

  • Una clave por dispositivo: cada teléfono, laptop o tablet tiene su propio par, registrado con nombre descriptivo en el wg0.conf (# Telefono Movil, # Laptop Trabajo, etc.).
  • Rotación periódica: cambia la clave privada del servidor cada 3-6 meses y reaplica a todos los peers. Para los clientes, rótalas al menos cuando cambies de dispositivo.
  • Desactivar el endpoint en peers pasivos: si un cliente solo se conecta desde dentro de la LAN, quita Endpoint y deja solo PublicKey y AllowedIPs. Cuando esté en Internet, se conectará por sí solo.
  • Limita el PersistentKeepalive: si el teléfono solo se conecta ocasionalmente, sube el keepalive a 30 o 60 segundos para reducir tráfico.
  • Logs: registra los handshakes en journald si necesitas auditoría. wg show no persiste nada por defecto.

Troubleshooting: qué hacer cuando no conecta

Estos son los fallos más comunes y cómo diagnosticarlos en orden:

Síntoma Causa probable Verificación
latest handshake: never Puerto 51820 no llega al servidor nc -uv tu.servidor.com 51820 desde el móvil (apps tipo "PingTools")
Handshake OK, no navega Reenvío IP deshabilitado sysctl net.ipv4.ip_forward en el servidor
Handshake OK, no navega Falta NAT masquerade iptables -t nat -L POSTROUTING -n -v
DNS no resuelve El servidor DNS interno no escucha en wg0 Probar con DNS = 1.1.1.1 en el cliente
Conecta pero pierde a los 30s Carrier hace NAT agresivo Subir PersistentKeepalive a 15
Solo conecta desde Wi-Fi Operador bloquea UDP saliente Cambiar puerto o usar TCP/443 con udp2raw

Si ninguno de los pasos anteriores resuelve, captura un handshake con wg show wg0 latest-handshakes y revisa journalctl -u wg-quick@wg0 -n 200 en el servidor. Los errores típicos vienen de claves mal copiadas (base64 distingue mayúsculas), de AllowedIPs duplicadas entre peers, o de un firewall corporativo que intercepta UDP. Verifica que las dos claves públicas coincidan: la del bloque [Peer] PublicKey del servidor debe ser igual a la PublicKey del bloque [Peer] en el archivo del cliente (la pública del servidor), y al revés para el cliente.

Resumen

Configurar WireGuard entre un servidor Linux y tu teléfono lleva menos de una hora y te devuelve acceso cifrado y soberano a toda tu infraestructura desde cualquier red. Genera claves con wg genkey, define el túnel en wg0.conf, activa reenvío IP y NAT, exporta el archivo del cliente a la app oficial y verifica con wg show. Mantén una clave por dispositivo, rótalas periódicamente y evita exponer puertos innecesarios. Cuando el túnel esté operativo, podrás llegar a tu NAS, Home Assistant o dashboards internos sin tocar la configuración del router ni contratar un proveedor SaaS adicional.

Preguntas frecuentes

¿Por qué Configura Wireguard en tu teléfono: Accede a todo desde cualquier lugar es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Configura Wireguard en tu teléfono:?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Configura Wireguard en tu teléfono:?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Configura Wireguard en tu teléfono: y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Configura Wireguard en tu teléfono:?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.

Lee también

Alfonso Moreno | Sysadmin Senior

Soy Alfonso, sysadmin senior con RHCE y más de 10 años administrando sistemas Linux para empresas y proyectos personales. Me especializo en infraestructura, redes, virtualización, monitoring, automation y self-hosting. Sobre SoyLinux.com SoyLinux.com es un blog técnico en español sobre Linux, software libre y self-hosting. Lo mantengo en mi tiempo libre. Áreas de expertise - Linux server administration: RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu - Network services: Postfix, BIND, Samba, NFS, Squid - Virtualización y containers: KVM, Proxmox, Docker, Podman - Monitoring: Prometheus, Grafana, Zabbix - Automation: Ansible, Bash scripting - Self-hosting: Vaultwarden, Nextcloud, Jellyfin, Immich, Homelab Contacto - Email: [email protected]

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *