VPN autoalojada en un VPS: WireGuard en diez minutos, y la privacidad que realmente compra

Qué hace realmente una VPN — y la frase que la mayoría de las explicaciones se saltan

Una VPN cifra tu tráfico y lo envía a un servidor, que lo descifra y lo reenvía. La consecuencia no es que tu tráfico se vuelva invisible. Es que cambia el conjunto de personas que pueden verlo. Antes: el Wi-Fi de la cafetería, el hotel, el operador móvil, tu ISP doméstico, y cualquier middlebox estatal que se sitúe por encima de todos ellos — todos ven qué sitios visitas y, más o menos, cuánto haces en cada uno. Después: ven un único flujo cifrado de larga duración hacia una sola dirección, y nada sobre lo que hay dentro. A cambio, la red en la que se asienta tu servidor pasa a ocupar la posición que los demás cedieron.

Ese es todo el mecanismo, y vale la pena decirlo sin rodeos, porque la versión de marketing — "sé invisible en línea" — hace que la gente espere una protección que el diseño no ofrece. Una VPN es un cambio de punto de observación. Que ayude o no depende por completo de si el nuevo punto de observación es mejor que el anterior para lo específico que te preocupa. Trasladar al observador de una red de hotel de la que nunca has oído hablar a un centro de datos que elegiste tú, en un país que elegiste tú, con software que configuraste tú, suele ser un intercambio muy bueno. Trasladarlo de tu ISP doméstico a una empresa que se anuncia en podcasts es un intercambio distinto, y menos evidente.

Autoalojarla cambia la segunda mitad de esa frase y nada más. La criptografía es idéntica — el documento de diseño de WireGuard describe el mismo handshake tanto si el peer es tuyo como si es de un proveedor. Lo que cambia es quién tiene la clave privada en el otro extremo, quién podría registrar el tráfico si quisiera, de quién existe una base de datos de clientes, y quién más comparte tu dirección de salida. Esas cuatro diferencias son todo el argumento a favor y en contra de montar la tuya propia, y no todas apuntan en la misma dirección.

Tu propia salida o una comercial: el intercambio que realmente estás haciendo

El instinto es tratar el autoalojamiento como la opción estrictamente más privada, y para la mayoría de los modelos de amenaza lo es. No hay un proveedor que conserve un registro de cuenta, ni infraestructura compartida que pueda ser confiscada por la cuenta de otra persona, ni una política de privacidad que haya que creer a ciegas, ni la posibilidad de un cambio en el registro de logs del que no te avisaron. Tú tienes la clave. No hace falta confiar en nadie, porque nadie está en posición de traicionarte.

Pero hay una dimensión en la que una VPN comercial gana sin discusión, y no es pequeña. Su dirección de salida la comparten cientos o miles de personas a la vez, así que un sitio web que ve una solicitud desde ella apenas aprende nada sobre cuál de esas personas la envió. Tu dirección de salida la compartes contigo mismo. Es estable, pertenece a un solo cliente, y cada sitio que visitas a través de ella ve el mismo identificador — exactamente como una IP doméstica, solo que en otro país. Si lo que buscas es perderte entre la multitud, una multitud de una sola persona no lo consigue.

Lee esa tabla como dos preguntas distintas, no como una sola puntuación. Si tu adversario es la red sobre la que estás — un ISP que vende datos de navegación, un lugar de trabajo que inspecciona el TLS, una cafetería, un hotel, un firewall censor — el autoalojamiento gana en todas las líneas que importan, porque aquello de lo que te escondes está por encima del túnel y no puede ver a través de él. Si tu adversario es el sitio que visitas, que intenta vincular la sesión de hoy con la del mes pasado, entonces la protección es la multitud, y una salida privada es peor que inútil. Muy poca gente está realmente en la segunda situación, y la mayoría de quienes lo están deberían estar leyendo sobre Tor en lugar de sobre VPNs.

La razón por la que la gente confunde ambas cosas es que la industria vende un mismo producto bajo las dos descripciones. La afirmación real y defendible de una VPN comercial es la multitud. Todo lo demás en el discurso comercial — la promesa de no guardar registros, las auditorías, la jurisdicción de constitución — es un intento de compensar el hecho de que estás entregando tu tráfico a una empresa. El autoalojamiento elimina a la empresa. Pero no puede fabricar una multitud.

Cuándo el autoalojamiento es la respuesta correcta

El caso más claro es una red que no controlas y en la que no puedes confiar. El Wi-Fi de una conferencia, hoteles, aeropuertos, la conexión compartida de un arrendador, el roaming móvil en un país con un régimen agresivo de interceptación legal. En todos esos casos la amenaza es local y pasiva, y un túnel hacia cualquier otro sitio la elimina por completo. Que este sea el caso de uso menos glamuroso no lo convierte en el menos valioso — es el que se aplica a casi todo el mundo, casi todas las semanas.

El segundo es la jurisdicción. Un túnel que sale por Zúrich significa que el tráfico que emerge de él se rige por la ley suiza, lo transporta un proveedor de tránsito suizo, y queda fuera del alcance de cualquier régimen que gobierne tu propia conexión. Eso no es una abstracción para quienes viven en países donde el ISP está obligado a conservar y entregar los registros de navegación. Elegir deliberadamente el país de salida es una de las pocas decisiones de privacidad con un efecto limpio y comprensible, y vale la pena leer la comparación de jurisdicciones antes de desplegar, no después.

El tercero es la censura. Los firewalls nacionales bloquean las VPN comerciales catalogando sus rangos de direcciones, lo cual es fácil porque esos rangos están publicados, se venden y se usan intensamente. Una única dirección de VPS en una red de hosting no figura en ninguna lista de esas — no porque sea astuta, sino porque nadie ha tenido motivo para catalogarla. Por eso las configuraciones de elusión más fiables siempre han sido pequeñas y personales, y no grandes y comerciales, y es el único lugar donde la multitud juega activamente en tu contra.

El cuarto es que quieres una salida estable, limpia y controlable para algo que no sea navegar: llegar a un home lab desde fuera, dar a un equipo pequeño acceso a servicios internos sin exponerlos, ejecutar un servicio que necesita una dirección de origen predecible, o mantener una sesión de larga duración sobre una dirección que no va a rotar bajo tus pies. Esos son problemas de ingeniería de red que una VPN comercial no puede resolver en absoluto, y que un VPS de $8.50 resuelve en una tarde. La página de la carga de trabajo VPN cubre el dimensionamiento y los detalles de red.

Y el argumento en contra: si no puedes mantener un servidor parcheado, no lo montes. Un VPS sin mantenimiento con un puerto SSH abierto da un resultado de privacidad peor que cualquier VPN comercial, porque una salida comprometida lo ve todo y responde ante otra persona. El autoalojamiento cambia un problema de confianza por un problema operativo. Ese es un buen intercambio solo si de verdad vas a ocuparte de la operación, que la última sección de esta guía reduce a unos diez minutos al mes.

WireGuard en diez minutos: la configuración completa

WireGuard es lo bastante pequeño como para poder leerlo entero. Vive en el kernel de Linux, habla por un único puerto UDP, usa un conjunto fijo de primitivas modernas sin negociación, y toda su superficie de configuración se reduce a dos tipos de bloque: un [Interface] que describe esta máquina, y un [Peer] por cada dispositivo autorizado a conectarse. No hay autoridades de certificación, no hay conjuntos de cifrado que elegir mal, y no hay ningún daemon que ajustar. Ese minimalismo es la razón por la que es difícil configurarlo mal de forma peligrosa, y la razón por la que ha sustituido a las alternativas en casi todas partes.

Empieza instalando el paquete y generando un par de claves. Establece primero umask 077 para que la clave privada no se escriba con permisos de lectura para cualquiera — wg-quick se quejará a gritos si lo está, y hace bien. wg genkey genera la clave privada, y wg pubkey deriva de ella la mitad pública. Haz lo mismo en cada cliente. Las claves públicas se intercambian; las privadas nunca salen de la máquina que las generó.

Después, escribe /etc/wireguard/wg0.conf. La tabla de abajo es el archivo completo de un servidor funcional — no se omite nada por brevedad.

Fuera del archivo, hay otras dos cosas que también deben cumplirse. El kernel debe estar dispuesto a reenviar: define net.ipv4.ip_forward=1 y net.ipv6.conf.all.forwarding=1, y escríbelos en /etc/sysctl.d/ para que sobrevivan a un reinicio. Y la regla NAT en PostUp debe nombrar la interfaz pública real — en la mayoría de las imágenes cloud es eth0, pero compruébalo con ip route get 1.1.1.1 en lugar de darlo por sentado. Un nombre de interfaz equivocado es, con diferencia, la razón más común por la que una primera instalación de WireGuard se conecta y luego no lleva a ningún sitio.

Levántala con wg-quick up wg0, confirma con wg show que la interfaz existe y lista tus peers, y luego ejecuta systemctl enable --now wg-quick@wg0 para que vuelva tras un reinicio. En el lado del cliente el archivo es casi idéntico, con tres diferencias que importan: AllowedIPs pasa a ser 0.0.0.0/0, ::/0 — lo que significa enruta todo a través de aquí en lugar de acepta estos orígenes — una línea Endpoint apunta a la dirección pública y al puerto del servidor, y PersistentKeepalive = 25 mantiene viva la asociación a través de routers domésticos que, si no, la dejarían caducar. Para los móviles, pasa la configuración del cliente por qrencode -t ansiutf8 y escanéala desde la terminal. No envíes los archivos de configuración por una app de mensajería; la clave privada está ahí dentro.

Las cuatro fugas que sortean el túnel

Un túnel que transporta tráfico no es lo mismo que un túnel que transporta todo el tráfico, y en la brecha entre ambos vive todo fallo real de una VPN. Cada una de las cuatro fugas siguientes es un caso en el que el túnel funciona perfectamente y tu tráfico lo está esquivando, y ninguna se anuncia por sí sola. Tienes que ir a buscarlas.

DNS. Si el cliente sigue usando el resolvedor que le asignó la red local, el túnel transporta tu tráfico mientras el servidor DHCP de la cafetería sigue recibiendo en directo cada dominio que consultas. Los nombres por sí solos son casi todo el panorama. Arréglalo poniendo una línea DNS = explícita en la configuración del cliente, o mejor aún, ejecuta un resolvedor en el VPS ligado a la dirección del túnel y apunta ahí a los clientes — así las consultas también atraviesan el túnel y terminan en una máquina que es tuya. Verifícalo desde el cliente, no desde el servidor, con cualquier test de fuga de DNS; deberías ver exactamente un resolvedor, y debería ser el tuyo.

IPv6. El clásico fallo silencioso. Si en el cliente AllowedIPs solo dice 0.0.0.0/0, le has dicho al sistema operativo que enrute IPv4 por el túnel y no le has dicho nada sobre IPv6. En una red dual-stack — que hoy es la mayoría de las redes domésticas y móviles — cada sitio que tiene un registro AAAA se alcanza por tu dirección real, fuera del túnel, mientras un test de fugas que solo comprueba v4 informa de que todo está bien. O añades ::/0 y repartes direcciones v6 dentro del túnel, o desactivas IPv6 en el cliente sin más. No hacer ninguna de las dos cosas es lo que viene por defecto, y ese comportamiento por defecto está roto.

La ausencia de un kill switch. Cuando el túnel se cae — el portátil se suspende, el móvil salta de una antena a otra, el servidor se reinicia por una actualización de kernel — el sistema operativo, queriendo ayudar, vuelve a la red local. El tráfico que creías que iba por el túnel ya no va, y nada te lo dice. En Linux, wg-quick con la tabla de enrutamiento por defecto ya bloquea la mayor parte del tráfico en caso de fallo, pero la solución fiable es una regla de firewall explícita que descarte todo lo que no salga por wg0. En Android e iOS, activa VPN siempre activada y Bloquear conexiones sin VPN. En los clientes de escritorio, comprueba si esa opción existe antes de dar por hecho que sí.

MTU. No es una fuga de privacidad, sino la razón por la que la gente tira la toalla. La encapsulación de WireGuard cuesta 60 bytes en IPv4 y 80 en IPv6, así que el MTU de interfaz por defecto, 1420, cabe dentro de una ruta normal de 1500 bytes. Sobre PPPoE, algunas redes móviles, o un segundo túnel, la ruta real es más pequeña, y el síntoma es peculiar: los pings funcionan, las páginas pequeñas cargan, y los handshakes TLS grandes se quedan colgados para siempre. Si eso es lo que estás viendo, baja el MTU del cliente a 1380 o 1280 y sencillamente empezará a funcionar.

Hay una cosa que una VPN no puede arreglar, y vale la pena decirlo para que no la esperes de ella: un observador que pueda vigilar ambos extremos a la vez puede correlacionarlos por su temporización y su volumen, haya túnel o no lo haya. El cifrado oculta el contenido, no la forma de una conversación. Defenderse de ese adversario exige mezclar tu tráfico con el de otras personas a través de múltiples relés, que es justo para lo que sirve Tor y lo que una VPN de un solo salto estructuralmente no es. Si ese es tu modelo de amenaza, una VPN autoalojada es la herramienta equivocada, y ninguna configuración la va a convertir en la correcta.

Hacer que la dirección de salida se comporte ahí fuera

La dirección desde la que sale tu túnel pertenece a una red de hosting, y buena parte de la web moderna clasifica las direcciones en residenciales y de centro de datos antes de decidir cómo tratarte. Los catálogos de streaming, algunos bancos, las webs de venta de entradas y buena parte de las herramientas antifraude tratan por defecto como sospechoso todo lo que venga de una red de hosting. Esto no lo arregla ningún cambio de configuración — es una propiedad de dónde vive el servidor, y se aplica igual a un túnel autoalojado que a cualquier VPN comercial del mercado. Quien prometa lo contrario está describiendo un juego del gato y el ratón que está perdiendo en este momento.

Lo que sí cambia es en qué listas aparece tu dirección. Los rangos de las VPN comerciales están catalogados, publicados y se venden como feeds precisamente porque son grandes, estáticos y compartidos; un sitio que quiere bloquear VPN compra esa lista. Una única dirección en una red de hosting generalista no aparece en ella. En la práctica eso significa que las salidas autoalojadas atraviesan sin problema una sorprendente cantidad de la web corriente que bloquea a los proveedores comerciales sin más, aunque sigan topándose con un muro en los servicios concretos que bloquean todo el tráfico de centros de datos. Espera algún CAPTCHA extra de vez en cuando y poco más.

Hay unas pocas cosas que merece la pena hacer una sola vez. Configura un registro DNS inverso simple y anodino en la dirección en lugar de dejar el que trae el proveedor por defecto — muchos sistemas de reputación leen el PTR, y un nombre de host genérico puntúa mejor que algo que suena a infraestructura. Mantén el túnel completamente alejado del puerto 25; el correo saliente desde una dirección de hosting recién estrenada acaba en la carpeta de spam hagas lo que hagas, y el problema de entregabilidad es un proyecto propio de varias semanas. Y si la dirección termina envenenada — heredada de un inquilino anterior, o por algo que hizo uno de tus propios peers — pide una reasignación de IP en lugar de pelear contra ello. Reasignamos la IP de los clientes a una dirección nueva dentro del mismo prefijo, sin coste; abre un ticket en el panel y queda resuelto en menos de un día.

La última consideración es quién más hay detrás de tu túnel. Como todos los peers comparten una única dirección de salida, el comportamiento de una persona se convierte en la reputación de todos. Un hogar no da ningún problema. Un grupo de veinte conocidos de los que no sabes qué hace la mitad es exactamente cómo una dirección limpia acaba bloqueada, y cómo un informe de abuso termina llegando con el nombre de tu cuenta puesto. Si vas a repartir peers más allá de gente por la que responderías, dales mejor su propia instancia — a $8.50 al mes es una respuesta más barata que la alternativa.

La capa que nadie configura: cómo pagaste el servidor

Este es el fallo que deshace todo lo anterior, y no tiene nada que ver con WireGuard. El tráfico sale de tu dirección de salida. La dirección pertenece a un servidor. El servidor pertenece a una cuenta. La cuenta se abrió con una dirección de correo y se pagó con una tarjeta a tu nombre. Llegados a ese punto, la cadena que va del tráfico hasta ti tiene cuatro saltos, está totalmente documentada, y reside en la base de datos de facturación de un proveedor esperando a que alguien pregunte. No has eliminado a un observador: lo has trasladado a un sitio con mejores registros.

Esta es la diferencia entre una VPN que cambia tu posición de red y una VPN que cambia tu exposición, y se decide en el proceso de pago, no en el archivo de configuración. Si la razón por la que quieres una salida privada es que tu ISP o tu gobierno no deberían tener tu historial de navegación, y el servidor está alquilado bajo tu identidad legal mediante un pago con tarjeta, el montaje sigue funcionando — el ISP realmente no puede ver a través del túnel. Pero es una mejora de privacidad frente a un observador concreto, no frente a uno decidido a llegar hasta el final. Ten claro tú mismo cuál de las dos cosas estás comprando.

Cerrar esa brecha significa que ni la cuenta pueda identificarte ni el pago tampoco. Eso implica ninguna verificación de identidad al registrarte — una dirección de correo desechable y nada más, que es lo que significa en la práctica el alojamiento sin KYC — y un pago por un riel que no lleve tu nombre. Monero es la respuesta limpia porque los importes y las partes no están en ningún libro contable público; el recorrido lleva unos cinco minutos de principio a fin. Bitcoin funciona, pero es un registro público permanente, así que solo es tan privado como lo sean las monedas que entran, y vale la pena leer la comparación entre ambos antes de decidir que no importa.

Luego está la jurisdicción, que determina qué podría llegar a exigir cualquiera aunque lo pidiera. Un proveedor constituido fuera de la esfera de los 14-Eyes, con centros de datos en países cuya ley de retención no exige conservar registros de tráfico, es estructuralmente incapaz de entregar un historial de navegación que nunca recopiló. Esa es una garantía más sólida que una promesa de no mirar. Para la versión completa de este argumento — qué es realmente rastreable de un servidor alquilado y qué no lo es — aquí tienes la respuesta honesta, incluidas las partes que son menos tranquilizadoras que el marketing.

Dimensionamiento: qué poco servidor necesita realmente un túnel

WireGuard es extraordinariamente barato de ejecutar. Vive en el kernel, así que los paquetes nunca se copian al espacio de usuario; usa ChaCha20-Poly1305, que es rápido en cualquier CPU y no depende de aceleración AES para seguir siéndolo; y guarda apenas unos kilobytes de estado por peer y nada más. Un solo núcleo moderno mueve algo así como un gigabit de tráfico cifrado, y la memoria prácticamente nunca es la limitación. El límite práctico en un túnel sobre VPS es el uplink, no el procesador.

Lo que significa que la mayoría de la gente elige un plan por la razón equivocada. Un hogar con cinco dispositivos navegando, viendo streaming y haciendo videollamadas todo el día ni se acerca a los límites del nivel más pequeño — la CPU está inactiva y el ancho de banda es ilimitado. Sube de nivel cuando tengas muchos peers simultáneos empujando tráfico real a la vez, o cuando quieras más margen en el uplink, no porque un túnel dé la sensación de que debería ser exigente.

La ubicación importa más que el hardware para cómo se siente el túnel. Cada paquete que envías da un rodeo por el servidor, así que tu latencia hacia cualquier destino pasa a ser tu latencia hasta el servidor más la latencia del servidor de ahí en adelante. Elige un centro de datos cercano a ti si el túnel está siempre activo y te importa la capacidad de respuesta; elige uno cercano a lo que quieres alcanzar si no lo está. Ámsterdam es el camino más corto de vuelta a la mayor parte de Europa, Zúrich y Reikiavik cambian unos milisegundos por jurisdicciones con leyes de privacidad más fuertes, y Bucarest se sitúa entre ambas en los dos aspectos.

Una cosa más que vale la pena saber antes de elegir: el handshake de WireGuard tiene una forma reconocible en el tráfico de red, y un firewall que haga inspección profunda de paquetes puede identificarlo y descartarlo sin saber nada sobre el destino. En la mayor parte del mundo esto nunca llega a pasar. En un puñado de redes significa que WireGuard por sí solo no va a conectar, y necesitas un transporte ofuscador delante de él — Shadowsocks, una pila xray o v2ray, o uno de los forks de WireGuard que rellena el handshake. Todos ellos corren en la misma instancia; es una capa que se añade encima, no un plan distinto.

Tenerlo funcionando durante años sin pensar en ello

La carga operativa de un endpoint personal de WireGuard es cercana a cero, pero no es cero de verdad, y esa diferencia es lo que separa una salida privada de una comprometida. Todo lo que viene a continuación es una configuración de una sola vez, salvo el último punto, que son unos diez minutos al mes.

Primero, blinda la puerta de entrada. SSH solo con claves — PasswordAuthentication no, PermitRootLogin prohibit-password — y un firewall que acepte exactamente dos cosas desde internet: el puerto UDP de WireGuard, y SSH. Si quieres ser minucioso, mueve el SSH para que solo escuche en la dirección del túnel, lo que significa que el único servicio alcanzable en la interfaz pública es el propio WireGuard, y WireGuard no responde en absoluto a paquetes no autenticados. Un escaneo de puertos del servidor entonces no devuelve nada, una propiedad realmente inusual para un servidor expuesto a internet.

Activa las actualizaciones de seguridad desatendidas y déjalas correr. Aquí el kernel importa de una forma en la que no importa en la mayoría de los servidores, porque la implementación de WireGuard forma parte de él. Reinicia cuando llegue una actualización de kernel; wg-quick@wg0 en systemd hace volver el túnel por sí solo, y los clientes con PersistentKeepalive se reconectan en segundos sin que nadie los toque.

Trata las claves como cuentas, porque eso es lo que son. Un par de claves por dispositivo, nunca compartido entre dos. Revocar el acceso consiste en borrar ese bloque [Peer] y ejecutar wg syncconf wg0 <(wg-quick strip wg0), lo que aplica el cambio sin cortar la sesión de nadie más. Haz copia de seguridad de /etc/wireguard/ en algún sitio cifrado y fuera de la máquina — perderlo significa volver a dar de alta cada dispositivo a mano. Si el servidor guarda cualquier otra cosa que te importe, el cifrado de disco completo es un añadido razonable, aunque para un túnel puro hay muy poco en el disco que merezca la pena cifrar más allá de ese directorio.

Monitoriza sin registrar. wg show te da la hora del último handshake de cada peer, que es suficiente para responder a cualquier pregunta operativa que realmente vayas a tener — si está activo, si este dispositivo está conectado, cuándo se conectó por última vez. Resiste la tentación de añadir contabilidad de tráfico o registros de conexión: construiste esto precisamente para que nadie guardara un registro de adónde va tu tráfico, y ahora la persona con más probabilidades de crear ese registro eres tú. Por nuestra parte no hay nada que desactivar — sin netflow, sin duplicación de puertos, sin ninguna captura de tráfico, y tablas ARP que caducan en 24 horas, lo cual está documentado en la página de privacidad y no solo prometido en un pie de página.

Eso es todo el trabajo. Quince líneas de configuración, un firewall, actualizaciones de seguridad programadas, y un vistazo mensual a wg show. Lo difícil de una VPN autoalojada nunca fue la VPN — es recordar que el túnel solo reubica al observador, y que todo lo que vale esa reubicación depende de que las cuatro fugas anteriores estén cerradas y de que la cuenta que hay detrás no lleve de vuelta hasta ti.