La versión de 3 segundos
Tu dispositivo cifra cada paquete saliente. Los paquetes cifrados viajan al servidor VPN. El servidor los descifra y los reenvía al internet público. Las respuestas vuelven por el mismo camino al revés. Las webs que visitas ven la IP del servidor VPN, no la tuya. Tu ISP ve ruido cifrado yendo a un servidor, no los destinos reales.
Ahora la versión más larga.
Paso 1: Setup de conexión (handshake)
Cuando tocas "conectar" en la app VPN, tu dispositivo y el servidor VPN realizan un handshake criptográfico para acordar una clave de sesión compartida. Es el único paso donde negocian qué cifrado usar. El handshake normalmente toma 50-100ms.
Para WireGuard (nuestro default), el handshake usa Diffie-Hellman de curva elíptica Curve25519, con BLAKE2s para hashing. La salida es una clave simétrica compartida que solo tu dispositivo y el servidor conocen. Forward secrecy está integrado: cada sesión nueva genera una clave nueva, así que aunque un atacante futuro recupere la clave de sesión de hoy, no puede descifrar sesiones pasadas.
Tanto tu móvil como el servidor terminan teniendo el mismo valor secreto, derivado vía matemáticas que no requieren mandar el valor por la red. La matemática (ECDH) es lo que hace esto posible. Tras el handshake, ambos lados pueden cifrar y descifrar usando esta clave compartida.
Paso 2: Cifrado de paquetes
Cada paquete IP que sale de tu dispositivo es interceptado por la app VPN antes de llegar a tu interfaz de red. La app:
- Toma el paquete original (ej., "GET / HTTP/1.1 a example.com").
- Lo cifra usando la clave de sesión compartida + un contador (para evitar ataques de replay) — ChaCha20-Poly1305 en WireGuard.
- Envuelve el payload cifrado en un paquete exterior nuevo direccionado a la IP pública del servidor VPN, no al destino original.
Desde la perspectiva de tu dispositivo, ahora estás mandando un stream de "paquetes VPN" a una sola IP — el servidor VPN. El destino original queda escondido dentro del payload cifrado.
Paso 3: Tunneling — el cable
Los paquetes cifrados atraviesan tu red local (WiFi o celular), cruzan la infraestructura de tu ISP y llegan al servidor VPN. Cualquiera observando este tráfico en medio (tu router, tu ISP, el WiFi de la cafetería, un observador pasivo en la red de la cafetería) ve:
- IP de origen: la IP real de tu dispositivo (la IP pública de tu conexión de casa, o tu IP celular).
- IP de destino: el servidor VPN.
- Payload: bytes cifrados que parecen ruido aleatorio.
Eso es todo. Pueden ver que hablas con un servidor VPN, pero no qué mandas ni a qué web quieres llegar eventualmente.
Paso 4: Salida en el servidor VPN
El servidor VPN recibe tu paquete cifrado, lo descifra usando la clave compartida y encuentra el paquete original dentro. Ahora necesita reenviar este paquete al destino real (example.com).
El servidor reemplaza la IP de origen del paquete con su propia IP (esto se llama Network Address Translation, NAT). Reenvía el paquete al internet público. Desde la perspectiva de example.com, la conexión viene de la IP del servidor VPN, no de ti.
Paso 5: Camino de respuesta (al revés)
Example.com manda una respuesta. Va a la IP del servidor VPN (que es la única dirección que conoce). El servidor VPN tiene una tabla NAT trackeando qué de sus conexiones pertenece a qué cliente VPN. Encuentra tu sesión, re-cifra la respuesta usando tu clave compartida y la reenvía a tu dispositivo. Tu dispositivo la descifra y entrega la respuesta original a tu navegador.
Tu navegador ve una respuesta normal a su request original. No tiene ni idea de que la respuesta fue ruteada por un VPN.
Qué ve cada parte
| Observador | Sin VPN | Con VPN |
|---|---|---|
| Tu ISP | Cada sitio que visitas + patrones de tráfico | Una conexión cifrada a un servidor VPN |
| Operador WiFi cafetería | Todo tu HTTP + consultas DNS + destinos | Un stream cifrado a una IP |
| La web (ej. example.com) | Tu IP real + ISP + ciudad aproximada | IP del servidor VPN + ubicación de datacenter |
| El proveedor VPN | — | Qué sitios visitas (a menos que el logging esté desactivado a nivel config — ver nuestra auditoría) |
| Tú | Internet directo | Internet cifrado, ligeramente más lento |
¿Qué pasa si el túnel se cae?
Las redes son poco fiables. Pasan handoffs de WiFi, los servidores se reinician, la señal celular fluctúa. Si el túnel VPN se cae a mitad de sesión, pueden pasar dos cosas:
- Sin kill switch: tu dispositivo vuelve a mandar paquetes por tu conexión normal del ISP. Durante unos segundos (hasta que el túnel reconecta), tu IP real y DNS quedan expuestos. Esta es la ventana de fuga que la mayoría del marketing "VPN sin logs" no menciona.
- Con kill switch (el nuestro, puesto por defecto): el SO bloquea todo el tráfico no-VPN cuando el túnel se cae. Las apps ven "sin internet" durante ~3-5 segundos mientras pasa la reconexión. Sin fuga. Detalles aquí.
El papel del DNS
DNS (Domain Name System) es cómo tu dispositivo convierte "example.com" en la dirección IP a la que debería conectarse. Error común en implementaciones VPN: cifrar el tráfico web real pero dejar que las consultas DNS se escapen al resolver de tu ISP. Tu ISP entonces ve "el usuario buscó youtube.com, facebook.com, hackernews.com" — que es la mayoría de lo que habría visto igualmente.
ClownVPN empuja DNS por el túnel por defecto. Las consultas van al 1.1.1.1 de Cloudflare por el túnel cifrado, no al resolver de tu ISP. La herramienta en /es/tools/dns-leak-test/ te deja verificar esto.
Arquitectura del lado del servidor (para curiosos)
Qué corre en un servidor VPN, brevemente:
- El demonio VPN en sí (módulo de kernel WireGuard + wg-go userspace, o servidor OpenVPN).
- NAT (Network Address Translation) para mapear el tráfico del cliente VPN a la IP pública del servidor.
- Un firewall para prevenir tráfico cliente-a-cliente y aislar la interfaz de gestión.
- Opcional: un sistema de logging. Nosotros lo desactivamos a nivel config — ver nuestra auditoría.
Nuestros servidores corren en RAM-disk así que incluso los logs a nivel sistema no persisten más allá de un reboot. El punto es hacer el logging arquitecturalmente difícil, no solo prohibido por política.
La matemática que puedes saltarte si no te interesa
Las primitivas criptográficas que usa ClownVPN, con márgenes de seguridad aproximados:
- ChaCha20-Poly1305 para cifrado simétrico. Nivel de seguridad ~256-bit. Más rápido que AES en CPUs sin aceleración hardware AES (la mayoría de móviles más viejos).
- Curve25519 para intercambio de claves ECDH. Nivel de seguridad ~128-bit. Claves pequeñas (32 bytes), cómputo rápido.
- BLAKE2s para hashing. Moderno, rápido, resistente a colisiones.
- AES-256-GCM en fallback OpenVPN para usuarios con redes que bloquean el puerto UDP de WireGuard.
Todos estos están revisados por pares, bien entendidos y han aguantado bajo criptoanálisis. Sin sorpresas aquí.