¿Cómo funciona una VPN?

¿Cómo funciona una VPN? Tu dispositivo construye un túnel encriptado a un servidor que vos elegís, manda cada paquete por ahí, y ese servidor reenvía tu tráfico al destino real usando su propia IP. Para cualquiera mirando la red entre vos y el servidor VPN, todo lo que ve es ruido encriptado yendo a una sola dirección. Para cualquiera mirando más allá del servidor VPN, tu tráfico parece haber salido del servidor, no de vos.

Esa es la versión de 30 segundos. El resto de este post desglosa cada paso con el detalle real de los protocolos, porque "túnel encriptado" es una frase que esconde mucha maquinaria interesante. Cubrimos qué pasa realmente durante un handshake VPN, qué significa encapsulación a nivel paquete, por qué el DNS tiene que ir por el túnel separadamente, cómo funciona el enmascaramiento de IP (no es magia, es NAT), y cómo difieren los tres protocolos principales en su plomería.

Escrito para gente que quiere entender el sistema sin un título en networking.

La versión de 30 segundos

Instalás un cliente VPN y le das a conectar. Detrás de escena:

1. El cliente y el servidor hacen un handshake. Cada uno demuestra quién es al otro y acuerdan claves de encriptación compartidas. Una o dos round trips.
2. Tu SO enruta el tráfico al túnel. El cliente le dice al SO "mandá todo por este adaptador de red virtual." El túnel ahora es la ruta por defecto.
3. Cada paquete se encripta, se envuelve y se envía. El paquete original (destinado, digamos, a Wikipedia) se encripta y se mete dentro de un nuevo paquete externo dirigido al servidor VPN. Desde la perspectiva de la red, sólo le estás hablando al servidor VPN.
4. El servidor desempaqueta y reenvía. Desencripta el paquete interno, ve a Wikipedia como destino, y lo manda con su propia IP como origen. Wikipedia le responde al servidor, que invierte el proceso.
5. El DNS pasa por el mismo túnel. Buscar wikipedia.org corre sobre el túnel encriptado y se resuelve en el servidor DNS del proveedor VPN, no en el de tu ISP.

Ese es todo el pipeline. El resto es variación en cómo se implementa cada paso.

Paso 1: el handshake e intercambio de claves

La encriptación sólo funciona si ambos lados acuerdan una clave. El handshake establece esa clave sobre una red donde cada byte está potencialmente siendo observado.

Los protocolos VPN modernos usan Diffie-Hellman o su variante de curva elíptica X25519 para esto. Dos partes generan cada una un par de claves pública-privada, intercambian las mitades públicas, y computan independientemente el mismo secreto compartido sin que ese secreto cruce nunca el cable. Un fisgón que captura cada byte no puede derivarlo.

Cada protocolo implementa esto de forma distinta:

WireGuard. Una round trip. Tu cliente envía una iniciación de protocolo Noise que contiene tu clave pública efímera y tu identidad (encriptada con la clave pública estática del servidor). El servidor responde con su clave pública efímera. Ambos lados derivan claves de sesión simétricas vía HKDF y empiezan a enviar datos. Tiempo de handshake en una red sana: 100ms o menos.

OpenVPN. Un handshake completo de TLS 1.2 o TLS 1.3, el mismo ida y vuelta que hace un navegador al conectarse a un sitio HTTPS. ClientHello, ServerHello, intercambio de certificado, intercambio de clave, finished. Más round trips, más bytes, más CPU. Tiempo de handshake: 500ms a más de un segundo en redes lentas.

VLESS Reality. Un handshake TLS 1.3 a un sitio web legítimo real (el target SNI). El protocolo Reality vincula criptográficamente la conexión al certificado TLS de ese target mientras enruta tráfico a un servidor VPN distinto. Para un observador de red, el handshake es indistinguible de alguien visitando el target SNI. La autenticación VPN pasa dentro de la sesión TLS vía identidad UUID.

Después del handshake, cada lado tiene claves de sesión simétricas. La encriptación simétrica es rápida; la asimétrica (de clave pública) es lenta. El handshake configura la sesión simétrica barata eficientemente. HTTPS usa el mismo patrón por la misma razón.

Paso 2: encapsulación, no tunelización física

La palabra "túnel" hace que la gente imagine alguna separación física, una carretera privada paralela a la internet pública. La realidad es más interesante. Un túnel VPN es simplemente encapsulación: poner un paquete dentro de otro paquete.

Imaginá un paquete IP regular yendo a Wikipedia. Tiene un encabezado (origen: tu dispositivo, destino: la IP de Wikipedia) y un payload (tu solicitud HTTP). Cuando el túnel está arriba, tu cliente toma el paquete entero, lo encripta, y lo mete dentro de un nuevo paquete externo dirigido al servidor VPN. El paquete original ahora está oculto dentro del nuevo sobre.

Los routers entre vos y el servidor VPN sólo ven el sobre externo. Enrutan basándose en el encabezado externo, que dice "mandá esto al servidor VPN." Una vez que llega, el servidor desencripta el payload, encuentra el paquete original adentro, y lo reenvía.

Este truco (un paquete IP envolviendo a otro) es el mecanismo detrás de cada protocolo de "tunneling" en internet. GRE, IPsec, WireGuard, OpenVPN: variaciones del mismo tema. La encapsulación pasa en el adaptador de red virtual que el cliente VPN instala (Wintun en Windows, TUN en Linux, utun en macOS). Tu SO ve una interfaz de red regular; el cliente VPN intercepta cada paquete enrutado ahí, lo encripta, y manda el resultado por la red real.

Paso 3: encriptación en tránsito

Una vez que el handshake produce claves de sesión, el protocolo las usa para encriptar cada paquete de tráfico. Las opciones de cifrado importan tanto para seguridad como para rendimiento.

ChaCha20-Poly1305. Cifrador de flujo con autenticación incorporada. Rápido en dispositivos sin aceleración AES por hardware (celulares más viejos, routers de gama baja). WireGuard usa esto exclusivamente. OpenVPN lo soporta. ChaCha20 es el default moderno para protocolos diseñados en la última década.

AES-256-GCM. El equivalente de cifrador de bloque. Las instrucciones de hardware AES-NI en cada CPU Intel y AMD desde 2010 hacen de éste la opción más rápida en hardware de escritorio. El default moderno de OpenVPN. WireGuard no lo usa (los autores de WireGuard eligieron deliberadamente ChaCha20 para evitar la dependencia de AES-NI para uso embebido).

AES-128-GCM. Misma familia, clave más corta. Marginalmente más rápido, marginalmente menos paranoico. Los protocolos modernos default a 256.

Las partes "GCM" y "Poly1305" son importantes: son tags de autenticación. La encriptación sola te dice que un atacante no puede leer tu tráfico; la autenticación te dice que un atacante no puede modificarlo sin detección. Una VPN que encripta pero no autentica está rota. Cada protocolo moderno usa encriptación autenticada (AEAD).

Cada paquete se encripta independientemente con un contador que previene ataques de replay. Si un atacante captura un paquete y lo reenvía después, la verificación del contador falla y el receptor lo descarta.

Paso 4: resolución DNS por el túnel

DNS es el sistema que convierte wikipedia.org en una dirección IP. Por defecto, tu SO manda consultas DNS al resolver que entregue DHCP, que usualmente es el de tu ISP. Eso pasa antes que cualquier tráfico web.

Sin manejo de DNS, una VPN filtra mucho. Conectás el túnel, tu navegador le pide al SO buscar bank.com, el SO manda la búsqueda al servidor DNS de tu ISP (fuera del túnel), y tu ISP obtiene una lista de cada dominio que visitás a pesar de que el túnel encriptado está haciendo su trabajo para el tráfico real.

Un cliente VPN correctamente implementado enruta el DNS por el túnel. Varios mecanismos:

Reemplazar el resolver DNS del sistema. El cliente setea el servidor DNS en la configuración de red del SO al resolver del proveedor VPN, que sólo es alcanzable por el túnel. Enfoque estándar.

Bloquear fugas DNS vía reglas de firewall. En Windows, el cliente VPN usa filtros del Windows Filtering Platform (WFP) para bloquear consultas DNS en cualquier interfaz que no sea el túnel. Cinturón y tirantes: aunque algo intente mandar una consulta DNS por la interfaz incorrecta, el firewall la dropea.

Deshabilitar smart-multi-homed name resolution. Windows por defecto manda consultas DNS a múltiples interfaces de red en paralelo y usa la que responda primero. Esta función de Windows, llamada SMHNR, filtra consultas DNS al resolver original provisto por el ISP cada vez que hacés una, incluso con una VPN activa. Un cliente VPN correcto deshabilita SMHNR vía NRPT (Name Resolution Policy Table) o entradas de registry.

Bloquear IPv6 si el túnel es sólo IPv4. Si tu red soporta IPv6 y la VPN no tuneliza IPv6, las consultas DNS IPv6 saltean el túnel por completo. O tunelizá IPv6 o bloquealo directamente.

El manejo de DNS es donde muchas VPN fallan en formas sutiles. Una VPN que encripta tráfico pero filtra DNS le entrega a tu ISP la misma metadata que tendría sin la VPN. Tenemos un post más profundo sobre fugas DNS si querés la versión cruda.

Paso 5: enmascaramiento de IP vía NAT

Cuando el servidor VPN reenvía el paquete interno a Wikipedia, tiene que tomar una decisión: ¿cómo sabe Wikipedia a dónde mandar la respuesta?

La respuesta es Network Address Translation (NAT). El servidor VPN reescribe la IP origen del paquete saliente desde tu IP del lado túnel a su propia IP pública, y registra el mapeo en una tabla NAT. Cuando Wikipedia responde, el servidor busca el mapeo, reescribe el destino de vuelta a tu IP del túnel, encripta el paquete, y lo manda de vuelta por el túnel. El mismo NAT que usa tu router de casa, sólo a escala.

Desde la perspectiva de Wikipedia, el origen de tu solicitud es la IP pública del servidor VPN. Wikipedia no puede derivar tu IP de casa de esa conexión. Pueden derivar que estás usando una VPN si cruzan la IP contra listas conocidas de salidas VPN (la mayoría de los sitios grandes lo hacen para detección de fraude), pero no pueden identificarte específicamente.

Esto también explica por qué las "IPs compartidas" son una ventaja de privacidad y una desventaja de usabilidad. Si cientos de personas están saliendo por la misma IP, el tráfico a un sitio dado no puede atribuirse a ninguna de ellas. La desventaja: las IPs compartidas son más propensas a ser flageadas o rate-limiteadas por sitios que desconfían de ellas (algunos bancos, algunos captchas, algunos servicios de streaming).

Paso 6: el truco de routing del SO

¿Cómo convence el cliente VPN a tu SO de mandar tráfico al túnel? No interceptando sockets individuales. El enfoque estándar es instalar un adaptador de red virtual y modificar la tabla de routing para que ese adaptador se vuelva la ruta por defecto.

El cliente agrega:

• Una nueva ruta por defecto a través del adaptador virtual (frecuentemente como rutas split 0.0.0.0/1 y 128.0.0.0/1 para sobrescribir la ruta por defecto existente sin removerla).
• Una ruta específica para la IP del servidor VPN a través del adaptador físico original, así los paquetes externos encriptados pueden efectivamente salir de tu dispositivo.
• Servidor DNS seteado al resolver del lado túnel.

Cada paquete saliente (excepto los dirigidos al servidor VPN) ahora se enruta al adaptador virtual. El cliente VPN los recoge, encripta, encapsula, y manda el resultado vía el adaptador físico. La función de kill switch vive en esta misma capa: si el túnel se cae, el cliente o mantiene las rutas apuntando a un gateway inexistente (el tráfico se va al blackhole) o instala reglas de firewall que bloquean tráfico hasta que el túnel reconecte.

Cómo difieren los protocolos en plomería

Cubrimos el esqueleto común. Cada protocolo llena los detalles distinto.

WireGuard. Sólo UDP. Handshake de tamaño fijo (148 bytes iniciación, 92 bytes respuesta). Sólo ChaCha20-Poly1305. Roams entre redes con gracia porque el estado de sesión está keado por las identidades estáticas, no por el par IP/puerto. Existen implementaciones en userspace (boringtun, la que usa Fexyn) pero también hay implementaciones en kernel. El tiempo de conexión es el más bajo de los tres: bajo un segundo, frecuentemente bajo 500ms en warm.

OpenVPN. UDP o TCP. Canal de control basado en TLS, canal de datos separado. Cifrador configurable (moderno: AES-256-GCM o ChaCha20-Poly1305). Sólo userspace, codebase más grande, más perillas de configuración. Handshake más lento, mayor overhead por paquete. El veterano de compatibilidad: funciona en redes donde WireGuard no, especialmente en modo TCP donde la conexión parece un stream TCP encriptado genérico.

VLESS Reality. Sólo TCP. El punto entero es parecer HTTPS ordinario para un observador de red. El handshake es un handshake TLS 1.3 real a un sitio legítimo real (configurado como el target SNI tanto en cliente como servidor). Dentro de esa sesión TLS, el protocolo VLESS lleva identidad (un UUID) y tráfico. El Vision flow (xtls-rprx-vision) que usamos agrega un framing interno de bajo overhead para el tráfico VPN. Más lento que WireGuard para throughput crudo pero sobrevive en entornos donde WireGuard y OpenVPN están bloqueados directamente.

Un cliente moderno elige por red. Redes rápidas y abiertas: WireGuard. Redes que bloquean WireGuard pero permiten TLS genérico: VLESS Reality. Redes que bloquean ambos pero permiten tráfico con forma de OpenVPN: OpenVPN como último fallback. El motor de rotación de Fexyn hace esto automáticamente.

Qué ve tu ISP, con VPN apagada vs prendida

VPN apagada. Tu ISP ve la IP de cada servidor al que te conectás, los dominios que consultás vía DNS, y cuánta data fluye cuándo. No pueden leer contenido HTTPS pero pueden leer SNI (el dominio en handshakes TLS), lo que les da la misma visibilidad de dominio desde otro ángulo.

VPN prendida, cliente bien implementado. Tu ISP ve una IP (el servidor VPN), bytes encriptados fluyendo hacia ella, y patrones de timing. Las consultas DNS pasan por el túnel, así que el ISP no puede leerlas. SNI ya no es visible para tu tráfico real, porque el único handshake TLS que el ISP ve es al servidor VPN (o al target SNI con Reality, que usualmente es un sitio popular que no revela nada sobre tu destino). Tu ISP usualmente puede fingerprint que estás usando una VPN, pero no qué sitios visitás a través de ella.

El cambio de confianza es visible en esta lista. Tu ISP pierde todo lo que tenía. El proveedor VPN lo gana. La política de logs y la confianza en el proveedor importan más que cualquier característica técnica individual.

Sobrecarga de rendimiento

Una VPN agrega dos costos: trabajo de encriptación en tu CPU, y un hop extra en la ruta de tu tráfico.

CPU. AES y ChaCha20 modernos se mueven a múltiples gigabits por segundo en un solo core. Para internet hogareño típico (bajo 1 Gbps), la sobrecarga de CPU es invisible.

Latencia. Agregar un hop agrega latencia proporcional a la distancia geográfica entre vos, el servidor VPN, y el destino. Una salida cercana agrega 5-20ms; un hop transcontinental agrega 100ms o más. Navegar y streaming absorben esto bien; el gaming competitivo no.

Throughput. WireGuard agrega cerca de 60 bytes por paquete (encabezados externos IP/UDP más tag de autenticación), aproximadamente 4% de overhead de framing en un MTU de 1500 bytes. El overhead de OpenVPN está más cerca del 10%. El golpe de throughput real es usualmente más grande que la matemática por paquete porque el servidor VPN puede ser un cuello de botella si está sub-dimensionado para su cuenta de usuarios. En nuestras propias pruebas, WireGuard cuesta 5-10% del ancho de banda total en una conexión sana; OpenVPN cuesta 15-25%. VLESS Reality se sienta entre ellos con más varianza por el framing TLS.

La conclusión

Una VPN funciona encriptando y encapsulando tu tráfico, mandándolo por un servidor elegido, y reenviándolo con NAT. El handshake establece claves de sesión. La encapsulación hace que los routers vean sólo el paquete externo. DNS, kill switch, y cambios en la tabla de routing atrapan los casos borde que de otro modo filtrarían tu identidad de red real.

El mecanismo está bien entendido y no es mágico. El beneficio de privacidad depende de qué parte estás enrutando, y qué hacen con lo que ven. Elegí un protocolo que matchee con tus condiciones de red, un proveedor que matchee con tus requisitos de confianza, y un cliente que maneje los vectores de fuga (DNS, IPv6, SMHNR, kill switch) correctamente.

FAQ

Paquetes IP encriptados y encapsulados. Tu paquete original (con su origen y destino real) se encripta y se mete dentro de un nuevo paquete externo dirigido al servidor VPN. Para cualquiera mirando la red, el paquete externo es todo lo que ven.

El paso de handshake usa criptografía de clave pública (X25519 en WireGuard, RSA o ECDHE en TLS para OpenVPN y Reality) para establecer claves de sesión simétricas sin que esas claves crucen nunca el cable. Una vez que ambos lados tienen las claves de sesión, cada paquete se encripta con un cifrador simétrico rápido (ChaCha20-Poly1305 o AES-256-GCM) que incluye autenticación incorporada.

Las búsquedas DNS pasan antes que el tráfico web y pueden filtrar independientemente del túnel. Por defecto, tu SO manda DNS al resolver que entregue DHCP, que usualmente es tu ISP. Un cliente VPN tiene que redirigir activamente el DNS al túnel y bloquear cualquier ruta de fuga (SMHNR de Windows, fallback IPv6, DoH del navegador evadiendo el DNS del SO).

TUN es una interfaz virtual de capa 3 (IP); TAP es una interfaz virtual de capa 2 (Ethernet). Las VPN casi siempre usan TUN porque sólo necesitan transportar paquetes IP. TAP es para casos de uso que necesitan emulación Ethernet, como puentear redes locales.

Sí, frecuentemente. Los paquetes WireGuard tienen una forma reconocible; OpenVPN sobre UDP tiene un encabezado distintivo. Incluso el tráfico encriptado tiene patrones de tamaño y timing que las herramientas de fingerprinting pueden usar. VLESS Reality es el más resistente porque imita TLS real a un sitio popular real. "Encriptado" e "indetectable" son problemas distintos.

Sin un kill switch, tu SO cae a la ruta por defecto original y el tráfico fluye en claro desde tu IP real. Con un kill switch, el cliente o mantiene la tabla de routing apuntando al gateway del túnel (ahora inexistente) (el tráfico va al blackhole) o instala reglas de firewall que bloquean todo el tráfico hasta que el túnel reconecte.

Sí, contra el operador de la red. El access point de Wi-Fi ve un túnel encriptado al servidor VPN. No pueden leer tu tráfico, ver qué sitios visitás, o inyectar contenido. HTTPS ya protege mucho de esto; una VPN agrega defensa en profundidad y protege metadata como SNI.

Handshake más chico (una round trip vs varias), menor overhead por paquete, codebase más simple que es más fácil de optimizar, y un diseño deliberado de cifrador único que evita overhead de negociación. WireGuard fue diseñado en 2015 con las lecciones de protocolos más viejos en mente.

En la red: no. Ven bytes encriptados a tu servidor VPN, lo mismo que tu ISP vería. En el dispositivo: tal vez. Si tu dispositivo de trabajo tiene software de gestión corporativa (MDM, EDR), ese software puede leer tráfico a nivel SO antes de que entre a la VPN. La privacidad a nivel de red es real; la privacidad a nivel de dispositivo depende del dispositivo.