Cómo montar tu propia VPN WireGuard en un VPS

Alquila un VPS sin KYC desde $4.80/mes (Core, anual), ejecuta la guía rápida oficial de WireGuard y mantén las claves y un solo puerto UDP en hardware cuyo root es tuyo.

La multitud es la ventaja, y también el problema

El argumento clásico a favor de una suscripción VPN comercial es la multitud: miles de desconocidos detrás de una única IP de salida compartida, de modo que ningún patrón puede atribuirse a una sola persona. El contraargumento que nadie imprime en la página de precios es que esa misma multitud produce los muros de CAPTCHA, los bloqueos de streaming y la reputación envenenada que hacen que las salidas compartidas sean un fastidio en el uso real. Cuando alquilas un VPS pequeño e instalas WireGuard tú mismo, el protocolo de debajo es idéntico al que las grandes marcas de consumo documentan abiertamente (wireguard.com), pero la IP de salida en el puerto 51820/udp sirve exactamente a una persona — y esa persona eres tú.

La propiedad es el mecanismo que hace el trabajo. Una suscripción de consumo te alquila una salida que no puedes inspeccionar, reiniciar ni regenerar; un VPS alquilado te entrega root en una máquina con su propia IPv4 pública, 2 vCPU de un Ryzen 9 9950X y 80 GB de NVMe en la línea de entrada Core, y te deja el túnel enteramente a ti. Las claves se generan en tus máquinas, toda la configuración del servidor cabe en un único archivo /etc/wireguard/wg0.conf, y un puerto sin límite de tráfico de 1 Gbps significa que el plan nunca será el cuello de botella. Outline (Jigsaw) vende el mismo modelo de propiedad tras un instalador más amable (getoutline.org), pero lo que compras de verdad es el modelo, no el instalador.

Aquí es donde el razonamiento se rompe: una IP en solitario no tiene multitud que la diluya. El perfilado de uso que se difuminaría entre miles de suscriptores recae en tu dirección sola, y esa dirección se vincula a una cuenta de hosting con tus credenciales. Ese es el precio honesto de ser dueño del punto de salida, y ningún túnel lo cifra y hace desaparecer.

Aun así, el intercambio merece la pena, porque renuncias al anonimato de la multitud y ganas la capacidad de reconstruir, regenerar o reubicar la salida en minutos. VPSbit alquila la máquina y no opera el túnel; nadie en la empresa llega a tener jamás una clave tuya. La siguiente pregunta es qué cambia exactamente cuando la criptografía sigue igual pero la responsabilidad cambia de manos — y la respuesta sorprende a quienes asumían que la app era la parte difícil.

Mismo protocolo, distinto responsable

Pasar de una suscripción a un túnel autoalojado no cambia nada en la criptografía y lo cambia todo en la responsabilidad. El diseño de WireGuard es deliberadamente pequeño: la descripción del protocolo detalla un handshake y un plano de datos implementados en unos pocos miles de líneas de código del kernel, cifrando con ChaCha20-Poly1305 y hasheando con BLAKE2s, ambos especificados públicamente en la RFC 8439. Mullvad, Proton VPN e IVPN ejecutan la misma construcción y la documentan abiertamente; lo que venden por encima es una app, una flota y la multitud de la sección anterior.

En tu propia máquina, la pila entera son tres piezas: el módulo del kernel, la herramienta de configuración wg y el envoltorio wg-quick que levanta una interfaz desde un solo archivo. Los instalas desde el repositorio de tu distribución en minutos — la página oficial de instalación cubre todas las distros — y activas el túnel con systemctl enable --now wg-quick@wg0. No hay ningún demonio que vigilar, ninguna base de datos que podar y ningún cliente del proveedor que se conecte a casa entre tu dispositivo y el cable.

El punto de ruptura: la gente importa la mentalidad de la app de cliente y espera que kill switches, ofuscación y rotación de direcciones aparezcan por arte de magia. WireGuard autoalojado no trae nada de eso. Un túnel que se cae retrocede silenciosamente a la interfaz física, así que el tráfico sale sin cifrar salvo que añadas una regla de firewall que solo permita salida a través de wg0. El manual de wg(8) lo dice sin rodeos — la herramienta configura, no supervisa.

Trata ese hueco como una lista de tareas pendientes, no como un defecto: las barandillas las construyes tú, y las que valen la pena aparecen más adelante en esta guía. A cambio obtienes un túnel cuyos componentes puedes leer todos en una tarde. Pero antes, mira de dónde nace realmente la seguridad — no en el servidor, sino en las máquinas que acuñan las claves.

Las claves se acuñan en tu lado del cable

La propiedad de seguridad más importante de este montaje jamás toca al proveedor: las claves privadas se generan en tus propias máquinas, y el servidor solo recibe claves públicas. La guía rápida oficial lo reduce a dos comandos — ejecuta umask 077 para que nada se cree legible por todos, y luego wg genkey | tee privatekey | wg pubkey > publickey para acuñar el par. Una clave privada que nunca sale del portátil que la creó no puede ser interceptada en reposo por nadie, incluida la empresa que te alquila el rack.

El enrutado criptográfico de WireGuard asigna cada peer a una clave: los bloques [Peer] del servidor listan la clave pública de cada dispositivo más las direcciones de túnel que puede usar, y nada más del dispositivo importa. Añadir una línea PresharedKey por peer — wg genpsk acuña una — superpone un secreto simétrico sobre el handshake, que es el seguro del diseño frente a futuros avances contra las curvas elípticas. El manual de ip(8) cubre la capa de enrutado sobre la que viajan las direcciones.

Por dónde se rompe en la práctica: un par de claves compartido entre un móvil y un portátil. Ambos dispositivos se reinician el handshake y se expulsan el uno al otro, la marca de tiempo del latest handshake salta entre ellos, y el tráfico se agujerea durante segundos de forma que parece un Wi-Fi malo. El otro clásico es colar un archivo privatekey ya usado en un repositorio de dotfiles o en una imagen de disco — una vez que una clave privada se ha copiado a cualquier sitio, considérala quemada y acuña un par nuevo.

La disciplina que compensa: un par por dispositivo, guardado en /etc/wireguard/ en el servidor y en el almacén de claves del sistema en los clientes, con el hábito de rotación asociado — un dispositivo que abandona la familia está a un wg set wg0 peer remove de no ser nada. Resuelta la identidad, la siguiente pregunta es cuánto del servidor debe poder ver el mundo exterior, y la respuesta es refrescantemente poco.

Un puerto UDP silencioso es toda la superficie de ataque

Aquí va la parte contraintuitiva: lo mejor que puede hacer tu punto VPN cuando un desconocido lo sondea es no hacer absolutamente nada. WireGuard nunca responde a paquetes no autenticados — ni banner, ni reset, ni respuesta de ningún tipo — así que un escaneo del 51820/udp ni siquiera puede demostrar que hay un servidor escuchando ahí. Ese silencio es el diseño, y reduce tu trabajo de firewall a algo que cabe en la cabeza: denegación por defecto y, después, abrir exactamente un puerto UDP para el túnel.

La mecánica son dos líneas en la mayoría de sistemas. nft add rule inet filter input udp dport 51820 accept abre el hueco, y ss -ulnp | grep 51820 confirma que la interfaz está enlazada y escuchando (ss(8) explica la salida). Todo lo demás — 22/tcp para tu propia administración, 80/tcp y 443/tcp si la máquina también sirve un sitio — es una decisión deliberada revisada por separado, nunca un efecto secundario del script de instalación.

El error clásico es probar desde el propio servidor: wg show en la máquina siempre parece sano y no demuestra nada sobre el camino que recorre un cliente real, porque localhost nunca cruza el filtro que acabas de escribir. Segundo clásico: activar el firewall del panel de hosting dejando vacío el firewall del invitado, o al revés, de modo que las dos capas discrepen sobre quién protege qué. Cuando discrepan, la más laxa suele ganar por accidente.

Un registro PTR correspondiente configurado desde el panel es opcional, un pulido — los túneles funcionan igual sin él, así que déjalo para cuando lo interesante funcione. Lo que decide si los desconocidos pueden encontrar el puerto es el intercambio de claves de la sección anterior, y lo que decide si tu tráfico puede escapar del túnel es la barandilla de la anterior aún; el puerto es solo la puerta. Después: quién tiene derecho a cruzarla.

Un peer por dispositivo, o el handshake más nuevo gana

Reutilizar una única configuración de peer en todos tus dispositivos parece ordenado y arruina el túnel sin hacer ruido. WireGuard mantiene exactamente una sesión por par de claves, así que cuando un móvil y un portátil comparten uno, cada nuevo handshake expulsa al otro: el dispositivo que acaba de hablar se queda la sesión, los paquetes del perdedor desaparecen a mitad de descarga, y obtienes fallos intermitentes que parecen el Wi-Fi de un hotel pero son tu propia configuración peleándose consigo misma.

La solución es estructural, no procedimental: un bloque [Peer] por dispositivo en el servidor, cada uno con su propio par de claves y su propia dirección de una subred que controlas — 10.8.0.0/24 es la elección habitual. En el cliente, AllowedIPs = 0.0.0.0/0 canaliza todo el tráfico por el túnel, mientras que AllowedIPs = 10.8.0.0/24 solo alcanza la propia máquina; decide por dispositivo, no por hogar, y el manual de ip(8) explica la semántica de enrutado de debajo.

La verificación es trabajo por peer: levanta un dispositivo, lee el lado del servidor con wg show wg0, y confirma que los contadores de transferencia de ese peer avanzan en ambas direcciones antes de que el siguiente se una. Escalonarlos así hace que una configuración problemática se delate de inmediato — los contadores se congelan en el cliente roto mientras los anteriores siguen fluyendo. Dar de alta los 4 dispositivos a la vez convierte una única línea AllowedIPs errónea en una tarde entera de adivinar cuál es la culpable.

Por dónde se rompe: los peers móviles tras un NAT de operador se quedan mudos. El servidor no puede iniciar hacia una dirección que no ve, así que el móvil deja de recibir hasta que habla primero; PersistentKeepalive = 25 lo arregla enviando un paquete vacío cada 25 segundos para mantener abierto el mapeo NAT. Segunda ruptura: los agujeros negros por path-MTU, donde los handshakes triunfan pero las transferencias grandes se atascan siempre en el mismo conteo de bytes — fijar MTU = 1420 dentro del bloque de interfaz resuelve la mayoría.

Con peers por dispositivo, la revocación pasa a ser una sola línea en lugar de una negociación doméstica, y la rotación deja de dar miedo hasta el punto de posponerse. Esa modularidad es también lo que hace indolora la reubicación del punto de salida, lo cual conviene — porque la ubicación de la salida es la única decisión de esta pila que la ley, y no la ingeniería, puede revocar.

La IP de salida hereda la ley del rack

Elegir dónde vive la máquina parece una cuestión de latencia y es en realidad una cuestión legal: la IP de salida está dentro de una instalación concreta, bajo una legislación concreta, y cada paquete que envías por el túnel emerge bajo esa jurisdicción. La guía de jurisdicciones clasifica las 12 sedes de VPSbit; la versión corta es que Ámsterdam responde en milisegundos, Reikiavik responde a la ley de retención y Zúrich responde al procedimiento. Nada en el túnel cambia con la bandera — todo en lo que pueden exigir a la máquina sí.

Lo comercial, en cambio, no cambia con la bandera: el mismo SKU se ofrece en cada ciudad, un único precio de lista cubre el mapa, y las diecinueve criptos se liquidan en el pago con una cuenta sin KYC — un token a secas, o un email más una contraseña de 12 caracteres. Los metadatos de conexión se conservan como máximo 24h; el payload y el tráfico del invitado no se registran. Tres sedes publican primas: Islandia y Noruega al +20%, Suiza al +35%, Luxemburgo al +15% — el resto factura al precio base de lista. La guía de pago con XRP muestra cómo moneda y ciudad siguen siendo desplegables independientes.

Pide Core a $6/mes de lista — $4.80/mes en el término anual — y pon el punto de salida en la ciudad que tu modelo de amenazas nombra realmente, no en la más barata; la página de despliegue toma plan, ciudad y moneda en una sola factura sin cargos automáticos que cancelar después. Un túnel para un puñado de peers no apura 2 vCPU ni un puerto sin límite de tráfico de 1 Gbps, así que el plan de entrada basta de sobra.

El punto de ruptura: asumir que la bandera legaliza el payload. No lo hace — la AUP viaja con cada SKU, el abuso se gestiona bajo la ley de la ubicación de la instalación, y el escaneo, el spam o los ataques a través de tu propio túnel son eventos de nivel de ban que aceptaste. Lo que cambia la bandera es qué tribunal tiene que pedir y cómo. Es una diferencia real; solo que no es la que insinúa el marketing, y por eso los límites merecen su propia sección.

El túnel cifra un tramo y nada más

Sé preciso con la geometría, porque la mayoría de las decepciones con las VPN son confusiones de geometría: un túnel WireGuard autoalojado cifra el tráfico desde tu dispositivo hasta el VPS y no más allá. Tu ISP de casa ve un flujo ilegible hacia una IP; el sitio web de destino ve la dirección del VPS, no la tuya. Todo lo que pasa de la máquina — el uplink del centro de datos, el camino hacia el destino, el destino mismo — sale como tráfico ordinario vistiendo la dirección wg0 del servidor.

Esa geometría viene con un libro de cuentas legible. En esta plataforma no hay registros de payload ni de tráfico de invitados, y los metadatos de conexión se conservan como máximo 24h; la facturación y las acciones del panel se conservan como registros comerciales normales. El contrato es con una empresa de San Cristóbal y Nieves, mientras que los discos están en una de 12 instalaciones cuya ley local gobierna cualquier procedimiento que llegue — dos capas, ambas descritas en la guía de jurisdicciones.

El DNS merece su propia frase en la geometría: un túnel enruta paquetes, no resoluciones, así que un cliente que conserve su resolver antiguo hará preguntas por el tramo equivocado con toda felicidad. Apunta el DNS de cada dispositivo al resolver del lado del túnel — DNS = 10.8.0.1 en el bloque de interfaz — y las consultas seguirán el mismo camino que todo lo demás. La mitad de los informes de «dejó de funcionar» en túneles por lo demás sanos son consultas DNS escapando de la interfaz envuelta, no paquetes saliendo de ella.

Por dónde decepciona el modelo: no es anonimato. El procedimiento legal que llega al rack llega a la máquina; la IP de salida se vincula a una cuenta de hosting; y todo lo que la AUP prohíbe — escaneo, spam, ataques — es conducta de nivel de ban aunque viaje por tu propio túnel cifrado. Un túnel es una frontera, las fronteras tienen dos lados, y el lado de fuera no es tuyo de controlar por muy de quién sea el hardware.

Lo que la frontera sí te compra es el control del lado de dentro: la máquina. Parchéala, mantén sus claves a raya, y seguirá siendo tuya en todos los sentidos operativos que importan día a día. Esa es la cuestión de mantenimiento que aborda la siguiente sección, porque la mayoría de los túneles autoalojados se pierden por abandono y no por atacantes — y el abandono tiene un calendario que sí puedes planificar.

Los puntos de salida mueren de abandono, no de atacantes

El fallo más común de una VPN autoalojada es aburrido: el kernel que arrancó el primer día sigue corriendo en el noveno mes, con CVEs conocidos contra su pila TCP o su implementación de WireGuard. Las actualizaciones de seguridad desatendidas cierran casi todo ese hueco — apt install unattended-upgrades en sistemas de la familia Debian activa una ejecución diaria que trae los parches de seguridad sin consultar tu agenda — y tras la primera activación no vuelves a pensar en ello hasta que algo fuerza un reinicio.

Los reinicios son la parte que la automatización no puede rematar por ti. Un kernel parcheado espera en memoria hasta que la máquina se reinicia, y /var/run/reboot-required es la bandera que indica que hay uno pendiente — compruébala semanalmente o reinicia en un calendario fijo que tú elijas. El orden completo, claves antes de firewall antes de parches antes de copias de seguridad, vive en la checklist de endurecimiento; un punto VPN es solo un objetivo de endurecimiento con exactamente un puerto UDP abierto, lo que lo hace de las máquinas más fáciles de mantener limpias.

Por dónde se rompe: actualizar la app cliente en todos los dispositivos mientras el SO del servidor se queda fuera de soporte. Una versión EOL deja de recibir precisamente el canal de parches de seguridad del que se alimenta la automatización, así que la máquina aparenta estar mantenida mientras el parcheado se detuvo en silencio. Segunda ruptura: systemctl restart wg-quick@wg0 derriba todas las sesiones de peers un momento, así que haz los cambios de configuración en horas tranquilas, y usa wg syncconf cuando una recarga sin caída baste para el cambio que haces.

El ritmo de mantenimiento es también el momento de notar el crecimiento. Si el túnel carga ahora un hogar, una oficina o una malla de enlaces site-to-site, el plan de entrada que lo llevaba cómodo puede tener la forma equivocada — y esa es una cuestión de escalado con una respuesta honesta, que a veces es un puerto más grande y a veces metal de verdad.

Cuando un puñado de peers se convierte en cuestión de rack

Core carga unos pocos peers sin despeinarse: 2 vCPU de un Ryzen 9 9950X a 4.3–5.7 GHz, 4 GB de DDR5 y un puerto sin límite de tráfico de 1 Gbps saturan mucho después de que lo haga un túnel personal. La escalera existe para las cargas que superan esa forma: el nivel intermedio duplica a 4 vCPU y 8 GB con 2.5 Gbps, y el nivel VPS superior pasa a 8 núcleos EPYC, 32 GB de memoria ECC y 10 Gbps. Cada peldaño es el mismo modelo de SKU, así que subir es un cambio de plan, no una migración.

El salto a dedicado es arquitectónico, no numérico: cuando la misma máquina tiene que ser un túnel y otra cosa — salida de oficina más correo más un servidor de builds — el hardware físico separado con acceso fuera de banda por IPMI empieza a justificarse. Forge son 16c / 32t del mismo 9950X con 2 x 1 TB de NVMe en RAID 0/1 y filtrado DDoS incluido; Summit y Monolith suben al territorio del dual-EPYC con puertos de 10 y 25 Gbps. Los niveles dedicados traen el mismo pago en cripto y el mismo modelo de cuenta sin KYC que las líneas VPS.

Alquila Forge a $49/mes de lista — $39.20/mes en el término anual — cuando el punto de salida hace de infraestructura compartida para una docena de personas en lugar de una familia de dispositivos de cuatro. IPMI significa que una edición de firewall que te deja fuera es una sesión de consola en lugar de un ticket de soporte, y los núcleos del 9950X mastican handshakes sin inmutarse. Para un túnel personal solo, eso sí, es capacidad que jamás tocarás.

El punto de ruptura: pasarse al metal antes de que la carga lo necesite cuesta ocho veces el dinero por un margen que una familia de peers nunca ejercita. Decide por la velocidad del puerto y el número de cotitulares, no por el encanto de la hoja de especificaciones. En cualquier caso, el runbook de abajo sigue idéntico — y precisamente por eso la guía termina con él.

La VPN WireGuard, en el orden de ejecución

Empieza en el pago: elige el plan, elige la ciudad, paga la factura con la que sea de las diecinueve criptos que tu wallet tenga, y la máquina se imagen en unos 60 segundos desde el pago hasta SSH. En el primer inicio de sesión, añade tu clave pública y desactiva la autenticación por contraseña antes de que nada más toque la red — la checklist de endurecimiento se encarga de esos pasos, y esta guía los hereda en lugar de repetirlos. A los quince minutos ya estás en la parte interesante.

Acuña las claves después: umask 077, luego wg genkey y wg pubkey por dispositivo, nunca un par compartido entre dos máquinas. Escribe /etc/wireguard/wg0.conf con la Address y el ListenPort de la interfaz, y luego un bloque [Peer] por dispositivo con su clave pública, su dirección de túnel de 10.8.0.0/24 y — para todo lo móvil — PersistentKeepalive = 25 para que los mapeos NAT sobrevivan a los períodos de inactividad.

Abre exactamente un hueco en un firewall de denegación por defecto — udp/51820 o el puerto que elegiste — confirma el listener con ss -ulnp, y levanta la interfaz al arrancar con systemctl enable --now wg-quick@wg0. Prueba desde un cliente real en una red ajena, nunca desde la propia máquina, y confirma ambas direcciones: el tráfico fluye por wg0, y nada se filtra alrededor cuando la interfaz cae. Configura el PTR opcional desde el panel solo cuando lo interesante ya funcione.

Después, mantenlo aburrido: lee /var/run/reboot-required semanalmente, rota la clave de cualquier dispositivo que abandone la familia, y revisa la decisión de ubicación una vez al año conforme la ley y la latencia se mueven alrededor de tus usuarios. Toda la secuencia — pedir, claves, configuración, puerto, activar, probar, mantener — son unos quince minutos la primera vez y cinco minutos al mes después, y el premio es una salida cuyas claves, configuración y jurisdicción puedes nombrar en cualquier momento sin buscarlas.