apt install y se configura con un fichero de 15 líneas./etc/wireguard, unos pocos KB. Un tar, un VPS nuevo y un registro DNS y estás en otro proveedor en diez minutos, con los clientes intactos.Casi todo el mundo tiene ya un motivo para levantar una VPN. Entrar al NAS de casa desde el móvil sin abrirlo a Internet, administrar servidores sin publicar el puerto SSH, trabajar desde una cafetería sin dejar la sesión al aire, o llegar a la impresora de la oficina desde el portátil. Y el reflejo habitual es contratar un servicio comercial con app bonita y suscripción mensual.
Para casi ninguno de esos casos hace falta. Con WireGuard montas la tuya en una tarde sobre cualquier Linux, y la diferencia importante no está en el precio, que es parecido, sino en algo que se ve el día que te quieres ir: tu VPN es un fichero de texto y unas claves. Cabe en un correo. Te la puedes llevar.
Este artículo va de las dos cosas: cómo se monta paso a paso, y cómo se muda de proveedor sin drama cuando toque.
WireGuard entró en el kernel principal de Linux con la versión 5.6 y desde entonces está en cualquier distribución moderna sin instalar módulos raros. La comparación con lo anterior es bastante brutal:
| WireGuard | OpenVPN | IPsec (strongSwan) | |
|---|---|---|---|
| Líneas de código | ~4.000 | Cientos de miles con OpenSSL | Decenas de miles |
| Dónde corre | Kernel | Espacio de usuario | Kernel + demonio |
| Rendimiento típico | 92-95 % del ancho de banda del enlace | 70-80 % | 85-90 % |
| Fichero de configuración | 15 líneas | Decenas de directivas + PKI | Varios ficheros y una CA |
| Reconexión al cambiar de red | Instantánea, sin sesión que renegociar | Segundos, a veces se cae | Depende de MOBIKE |
Las 4.000 líneas no son una curiosidad de programador. Son la razón de que una persona pueda auditar el código entero en una semana, y de que la superficie de ataque sea la que es. OpenVPN arrastra OpenSSL con todo lo que eso implica; IPsec lleva décadas de opciones acumuladas y negociación de parámetros.
La otra virtud práctica: WireGuard no tiene concepto de sesión. No hay login, ni renegociación, ni túnel que se caiga al pasar del wifi a los datos del móvil. Los paquetes se cifran con la clave del par que corresponda y punto. Cierras el portátil, lo abres en otro sitio y el túnel sigue.
Y un detalle de seguridad que se agradece: el servidor es silencioso. Si un paquete no viene autenticado con una clave conocida, WireGuard no contesta nada. Un escaneo de puertos no ve un servicio ahí. No hay banner que enumerar ni versión que buscar en un CVE.
Antes de la parte práctica conviene dejar claro para qué sirve esto, porque la palabra «VPN» se usa para dos cosas muy distintas.
Lo que hace bien una VPN propia:
Lo que no hace, por mucho que te lo vendan:
Si lo que buscas es esconderte de la publicidad o ver el catálogo de otro país, un servicio comercial hace mejor ese trabajo. Si lo que quieres es llegar a lo tuyo desde cualquier sitio y que nadie lo vea, sigue leyendo.
| Dónde | Coste | IP pública | Cuándo elegirla |
|---|---|---|---|
| Miniordenador, Raspberry Pi o NAS en casa | 0 € más 2-5 W de consumo | La de tu operador, y puede cambiar | Quieres llegar a tu red doméstica y ya tienes el cacharro encendido |
| VPS de 1 vCPU / 1 GB | 4-8 €/mes en un proveedor español | Fija y dedicada | Quieres IP estable, salir a Internet por ahí o esquivar el CG-NAT |
| Máquina en tu infraestructura | Lo que ya pagas | La de tu rango | Ya tienes cloud privado o servidores propios y esto es una VM más |
Para casi todo el mundo la respuesta es la primera si ya hay hardware en casa, y la segunda si hace falta IP fija. Un VPS de gama de entrada mueve WireGuard con soltura: el cifrado va en el kernel y el cuello de botella lo pone el ancho de banda del proveedor, no la CPU.
La tercera es la que aparece en cuanto la VPN deja de ser cosa tuya y empieza a dar acceso a un equipo entero, con lo que eso arrastra de altas, bajas y auditoría.
Los ejemplos son de Debian y Ubuntu. En Rocky o Alma cambia el gestor de paquetes y poco más.
sudo apt update
sudo apt install -y wireguard qrencodewireguard trae las herramientas de espacio de usuario, y el módulo del kernel ya está desde la 5.6. qrencode es opcional pero viene de perlas para dar de alta móviles: en vez de copiar un fichero, pintas un QR en la terminal y lo escaneas con la app.
umask 077
wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.keyOjo con el umask 077 de la primera línea, que no es decorativo: sin él la clave privada se queda legible por cualquier usuario del sistema. Esas dos claves son tu VPN. Guárdalas donde guardas las cosas serias.
Si quieres que el tráfico de los clientes salga a Internet o llegue a tu red local, el servidor tiene que hacer de router:
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-wireguard.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-wireguard.conf
sudo sysctl --systemAntes de escribirlo, mira cómo se llama la interfaz de salida, porque eth0 es una suposición que falla en la mitad de los VPS modernos:
ip route show defaultAhora /etc/wireguard/wg0.conf:
[Interface]
Address = 10.66.66.1/24, fd42:66:66::1/64
ListenPort = 51820
PrivateKey = <contenido de server_private.key>
PostUp = iptables -t nat -A POSTROUTING -s 10.66.66.0/24 -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -A POSTROUTING -s fd42:66:66::/64 -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.66.66.0/24 -o eth0 -j MASQUERADE
PostDown = ip6tables -t nat -D POSTROUTING -s fd42:66:66::/64 -o eth0 -j MASQUERADECuatro decisiones metidas ahí:
10.66.66.0/24 es el rango interno del túnel. Elige uno que no choque con tu red de casa ni con la del hotel donde vas a acabar conectándote; el clásico 192.168.1.0/24 es la peor idea posible.fd42::/8), porque cada vez más sitios son IPv6-only y un túnel que solo lleva IPv4 se queda cojo.ListenPort = 51820 es el puerto por defecto. Cambiarlo a un puerto alto cualquiera no es seguridad de verdad, pero quita ruido de los escaneos automáticos.PostUp/PostDown montan y desmontan el NAT de salida. Si solo quieres llegar a la red interna y no salir a Internet por el túnel, puedes prescindir de ellos.Un aviso sobre SaveConfig = true, que aparece en muchos tutoriales: al parar el servicio, WireGuard reescribe el fichero con el estado en memoria y te borra los comentarios y el orden. Si vas a llevar la configuración a mano, déjalo fuera.
sudo systemctl enable --now wg-quick@wg0
sudo wg showSi el servidor tiene firewall, abre el puerto UDP:
sudo ufw allow 51820/udpCada dispositivo tiene su par de claves. La privada no sale nunca del dispositivo.
umask 077
wg genkey | tee portatil_private.key | wg pubkey > portatil_public.key
wg genpsk > portatil_psk.keyEsa tercera clave, la preshared key, es un secreto simétrico adicional que se suma al cifrado normal. No es imprescindible, pero cuesta un comando y protege el túnel frente a un futuro atacante con ordenador cuántico que hubiera estado guardando tráfico. Ponla.
Ahora se añade el cliente al fichero del servidor:
[Peer]
# portatil de trabajo
PublicKey = <contenido de portatil_public.key>
PresharedKey = <contenido de portatil_psk.key>
AllowedIPs = 10.66.66.2/32, fd42:66:66::2/128Y se recarga sin tirar el túnel de los demás:
sudo wg syncconf wg0 <(wg-quick strip wg0)El fichero del cliente, portatil.conf:
[Interface]
PrivateKey = <contenido de portatil_private.key>
Address = 10.66.66.2/32, fd42:66:66::2/128
DNS = 1.1.1.1
[Peer]
PublicKey = <contenido de server_public.key>
PresharedKey = <contenido de portatil_psk.key>
Endpoint = vpn.tudominio.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25Tres cosas que deciden cómo se comporta:
AllowedIPs = 0.0.0.0/0, ::/0 manda todo el tráfico por el túnel. Si solo quieres llegar a tu red interna y que el resto salga normal, pon ahí 10.66.66.0/24, 192.168.10.0/24 y tendrás túnel dividido. En el móvil, el túnel completo gasta más batería.DNS solo tiene efecto si el cliente puede aplicarlo. En Linux hace falta openresolv o resolvconf instalado, y si apuntas al propio servidor VPN tienes que tener ahí un resolver, un unbound o un dnsmasq escuchando. Si no, resolución rota y media hora de desconcierto.PersistentKeepalive = 25 manda un paquete cada 25 segundos para mantener viva la traducción de NAT del router intermedio. Sin él, el servidor no puede iniciar la conversación con un cliente que está detrás de NAT.Para el móvil, el QR:
qrencode -t ansiutf8 < portatil.confSe escanea desde la app oficial de WireGuard y listo. Y borra el .conf del disco después, que se queda ahí con la clave privada dentro.
Comprueba que funciona: curl -4 ifconfig.io desde el cliente debe devolver la IP del servidor, y sudo wg show en el servidor debe mostrar un latest handshake reciente.
Aquí está la ventaja de verdad, y no aparece en las comparativas de precio.
Con un servicio comercial contratas una relación. Instalas su app, aceptas su protocolo, confías en su política de registros, y el día que suben el precio, cambian de dueño o dejan de gustarte, empiezas de cero: otra cuenta, otra app, otra configuración en cada dispositivo. No te llevas nada porque nunca tuviste nada.
Tu VPN cabe en un directorio:
sudo tar czf wireguard-backup.tar.gz -C /etc wireguard
ls -lh wireguard-backup.tar.gzUnos pocos KB. Ahí dentro está todo lo que define tu red privada: la clave del servidor, el rango interno, la lista de dispositivos autorizados y sus claves públicas. Eso es la VPN. El VPS que la ejecuta es un detalle reemplazable.
Digamos que quieres cambiar de proveedor o de país. La receta completa:
# 1. En el servidor viejo: copia de seguridad
sudo tar czf ~/wg.tar.gz -C /etc wireguard
# 2. En el servidor nuevo: mismo paquete
sudo apt install -y wireguard
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
# 3. Restaurar
sudo tar xzf wg.tar.gz -C /etc
# 4. Ajustar el nombre de la interfaz de salida si es distinto
ip route show default
sudo sed -i 's/eth0/ens3/g' /etc/wireguard/wg0.conf
# 5. Arrancar
sudo systemctl enable --now wg-quick@wg0Y el paso que lo cierra: cambiar el registro DNS de vpn.tudominio.com a la IP nueva. Nada más. Los clientes no cambian ni una línea, porque su Endpoint apunta a un nombre, no a una IP.
Por eso conviene usar siempre un nombre de dominio en Endpoint, nunca la IP directa. Cuesta lo mismo el día que lo configuras y te ahorra tocar cada dispositivo el día de la mudanza. Baja el TTL del registro a 300 segundos un rato antes de mover nada.
Un matiz importante que se salta mucha gente: WireGuard resuelve el nombre una sola vez, al levantar la interfaz. Si cambias la IP con el túnel arriba, el cliente sigue mandando paquetes a la dirección vieja hasta que reinicies el túnel (wg-quick down wg0 && wg-quick up wg0, o el interruptor de la app). Para el lado del servidor con pares dinámicos, el propio proyecto distribuye un reresolve-dns.sh en contrib que se puede lanzar por temporizador.
La misma propiedad sirve para lo contrario: en lugar de mover la que tienes, montas otra al lado. Repites el fichero con otro rango (10.77.77.0/24), otro puerto y otro nombre de interfaz, y en el cliente tienes dos perfiles: wg0 que sale por Madrid y wg1 que sale por Lisboa. Se activa el que interese en cada momento, y en Linux pueden convivir levantados a la vez, cada uno con sus AllowedIPs para repartir qué va por dónde.
Esto abre un uso muy práctico: una VPN por propósito. Una para llegar a la red de casa, en el miniPC del salón, con túnel dividido. Otra en un VPS para salir a Internet con IP fija cuando estás fuera. Cuestan poco y no se estorban.
| VPN comercial | VPN propia con WireGuard | |
|---|---|---|
| Coste | 3-6 €/mes por usuario, casi siempre con permanencia anual | 0 € en hardware propio, 4-8 €/mes en VPS, usuarios ilimitados |
| Salida a Internet | Cientos de IP en decenas de países | Una IP fija, la tuya |
| Anonimato frente a webs | Te diluye entre muchos usuarios | Ninguno, te identifica |
| Acceso a tu red | No, o de pago aparte | Es su motivo de existir |
| Quién ve tus registros | Ellos, según su política | Tú, y solo si decides guardarlos |
| Cambiar de proveedor | Empezar de cero | Un tar y un registro DNS |
| Quién arregla las averías | Su soporte | Tú, a las tres de la mañana |
Esa última fila es la parte incómoda y hay que decirla: montar la tuya significa que el día que el VPS se cae o el certificado del panel caduca, el de guardia eres tú. Para un uso personal o de un equipo pequeño, es asumible. Para dar acceso remoto a una plantilla entera, hay que decidirlo con los ojos abiertos.
Muchos operadores ya no dan IPv4 pública dedicada: reparten una entre varios clientes con CG-NAT, que es la factura oculta que sostiene IPv4. Con CG-NAT no puedes abrir un puerto entrante hacia tu casa, así que la VPN doméstica no acepta conexiones de fuera.
La salida es un VPS barato haciendo de punto de encuentro. El servidor de casa se conecta hacia el VPS con PersistentKeepalive, tus dispositivos móviles también, y el VPS enruta entre unos y otros. La casa no necesita puerto abierto: la conversación siempre se inicia desde dentro. Es exactamente la misma idea que usan por debajo las mallas tipo Tailscale o NetBird, solo que aquí el nodo intermedio es tuyo.
Alternativa gratis: pedir IPv6 al operador, si lo da. Con IPv6 nativo cada equipo tiene dirección propia y el problema desaparece.
wg-quick pone 1420 bytes por defecto, que va bien en la mayoría de conexiones. Con PPPoE o con algún operador móvil el resultado es un túnel que levanta, hace ping y no carga ninguna web. Si te pasa eso, baja la MTU:
[Interface]
MTU = 1360Es el síntoma más despistante de WireGuard: parece que funciona, y no funciona.
Con AllowedIPs = 0.0.0.0/0 el tráfico va por el túnel, pero las consultas DNS pueden seguir yendo al resolver del wifi al que estás conectado, que ve la lista de dominios que visitas. Comprueba desde el cliente que la salida es la que esperas, y si montas tu propio unbound en el servidor de la VPN, mejor todavía: consultas cifradas hasta tu servidor y resolución hecha ahí.
WireGuard no lleva registros de conexión, pero wg show sí enseña la última IP de origen y el último handshake de cada par. El sistema operativo puede estar guardando más de lo que crees en journald.
En el momento en que la VPN la usan otras personas (empleados, colaboradores, clientes), esos datos son datos personales y tú eres el responsable del tratamiento. Toca decidir a conciencia qué se guarda, cuánto tiempo y quién puede mirarlo, igual que con cualquier otro sistema. Que sea tu servidor no te exime, más bien al contrario.
Si pierdes /etc/wireguard, pierdes la VPN entera y hay que dar de alta cada dispositivo otra vez. Guarda el tar cifrado, en dos sitios:
sudo tar czf - -C /etc wireguard | gpg -c > wg-$(date +%F).tar.gz.gpgY si un dispositivo se pierde o alguien deja el equipo, borra su bloque [Peer] del servidor y recarga con wg syncconf. Revocar es eso: quitar cuatro líneas.
Con cinco dispositivos, editar el fichero a mano va perfecto. Con treinta, no. Ahí entran los paneles: wg-easy es el más extendido, corre en un contenedor Docker con interfaz web para crear clientes y descargar sus QR, y va por la versión 15, que reescribió la configuración por variables de entorno y la movió al panel. Si lo montas, protege esa interfaz detrás de la propia VPN o de un proxy con autenticación, porque quien entra ahí puede crear pares nuevos.
Todo lo anterior está pensado para una persona, un equipo pequeño o un homelab. Hay un momento en que este montaje deja de ser suficiente, y suele reconocerse por alguna de estas señales:
La buena noticia es que la portabilidad sigue jugando a tu favor en ese salto: la misma configuración que corría en un VPS corre igual en una máquina virtual dentro de tu propio cloud privado, con copia, alta disponibilidad y un contrato detrás. Cambias dónde se ejecuta, no cómo funciona.
Si estás en ese punto y quieres que el acceso remoto deje de depender de un servidor suelto, échale un ojo a nuestro cloud privado o cuéntanos cómo entra hoy tu gente a la infraestructura. La conversación útil empieza por quién tiene que llegar a qué, no por qué protocolo usar.
Cero si la pones en un miniPC, una Raspberry Pi o el NAS que ya tienes enchufado; entre 4 y 8 € al mes si prefieres un VPS de 1 vCPU y 1 GB en un proveedor español, con IP fija incluida. No hay coste por usuario, así que la diferencia con un servicio comercial crece con cada dispositivo que añades.
Sí. Cifrar tus propias comunicaciones y acceder a tu propia red es completamente legal. Otra cosa es lo que hagas a través del túnel, que responde a las mismas normas que cualquier otra conexión. Y si das acceso a terceros, entras en el terreno del tratamiento de datos personales con las obligaciones que eso conlleva.
Mal. Las plataformas de vídeo bloquean rangos de datacenter desde hace años, y tu VPN sale por una IP de VPS perfectamente identificable como tal. Para ese uso concreto un servicio comercial funciona mejor, sin más vueltas.
Que no puedes recibir conexiones entrantes en casa. La solución práctica es poner el servidor WireGuard en un VPS con IP pública y que tanto tu servidor doméstico como tus dispositivos se conecten hacia él con PersistentKeepalive. La otra vía es IPv6 nativo, si tu operador lo ofrece.
Sí, con una condición: que el Endpoint de los clientes apunte a un nombre de dominio y no a una IP. Copias /etc/wireguard al servidor nuevo, ajustas el nombre de la interfaz de salida si cambia, arrancas el servicio y actualizas el registro DNS. Los clientes solo necesitan reiniciar el túnel para volver a resolver el nombre.
Tailscale, NetBird y Firezone usan WireGuard por debajo y le añaden lo que aquí haces a mano: descubrimiento entre pares, atravesar NAT sin puerto abierto, identidad y panel. Para mallas de muchos dispositivos ahorran trabajo real. A cambio, hay un servicio de coordinación de un tercero en medio, con la salvedad de que el plano de control de Tailscale es autoalojable con Headscale y NetBird y Firezone son de código abierto. WireGuard a pelo es más trabajo y ninguna dependencia.
Sí, y es una de sus mejores propiedades. Cada túnel es una interfaz independiente (wg0, wg1) con su rango, su puerto y sus pares. En Linux pueden estar levantados a la vez repartiendo el tráfico por AllowedIPs; en las apps de móvil se activa uno cada vez.
wg-quick(8) y wg(8) — PostUp, AllowedIPs, MTU, SaveConfig y el resto de directivas.
Por qué hubo que inventar los dominios, quién registró los primeros .com y qué fue de ellos, las ventas que han hecho historia (AI.com por 70 millones de dólares, la mayor conocida) y la evolución completa del precio de un .com desde que era gratis hasta la subida a 10,97 dólares anunciada para noviembre de 2026. Con el gráfico, la tabla de valores y lo que conviene hacer antes de que suba.
La explicación de barra de bar dice que HTTP/3 va sobre UDP porque UDP es más ligero. La razón de verdad es otra: TCP vive en el kernel y treinta años de NAT, cortafuegos y balanceadores se aprendieron su comportamiento de memoria. QUIC se llevó la fiabilidad, el control de congestión y el cifrado al espacio de usuario para poder volver a tocarlos. Qué gana con eso, qué factura paga en CPU y qué te cambia a ti si operas la infraestructura por la que pasa ese tráfico.
En 2007 un binario de Google tardaba 45 minutos en compilar y sus 4,2 MB de fuentes se convertían en 8 GB al expandir los #include. De esa frustración salieron Go y una idea incómoda: quitar opciones al programador. Casi veinte años después, Docker, Kubernetes, Prometheus y media docena de herramientas que administras a diario son binarios de Go. Qué cambia eso en tu operación, y qué te obliga a hacer distinto al parchear.