¿Puede el operador de una VPN ver qué sitios visita?
Un servidor OpenVPN predeterminado registra sesiones, no URL. Compare los registros de conexión, una captura del túnel y una prueba de fuga de DNS antes de afirmar qué ve el operador.
Pregunte qué puede ver la VPN y la respuesta depende de dónde se sitúe en la ruta. En la capa de sesión el operador tiene eventos de autenticación y recuentos de bytes. En la capa de paquetes tiene direcciones de destino y tiempos. En la capa de DNS puede tener los nombres mismos. Cada capa responde a una pregunta distinta, y ningún interruptor le mueve entre ellas.
Trace la capa antes de afirmar nada
La misma conexión produce registros distintos en cada punto, y una afirmación sobre privacidad solo tiene sentido cuando nombra el punto. Lea la tabla columna por columna: qué existe en esa capa, qué puede ver allí un operador y qué siguen sin poder decirle esos mismos registros.
| Layer | Visible there | Not visible there |
|---|---|---|
| Session and authentication | Account, client address, start and stop times, assigned address, byte counts | URLs, page content, search terms |
| Forwarded packets | Destination address and port, sizes, timing, often the TLS server name | HTTP path, headers, response body |
| DNS resolver | Queried names and the client that asked | Page content and later requests |
| TLS-terminating proxy | Full request line, headers and body | Nothing, by design |
Leer una sola capa como si fuera toda la imagen es como empiezan tanto las exageraciones como la falsa tranquilidad. Un proveedor que dice que no registra la navegación puede ser exacto sobre el registro de URL y aun así guardar registros de sesión, y una captura de paquetes que solo muestra direcciones no se convierte en historial de navegación sin búsquedas inversas y conjeturas.
Cuando evalúe una política, busque la frase que describe cada capa. Si la política no las separa, pregunte qué registros existen en lugar de aceptar una declaración general sobre el cifrado.
Inventario de sesiones: qué guarda un servidor OpenVPN estándar
Tal como sale de fábrica, un servidor OpenVPN no captura tráfico. La salida normal es un inventario de sesiones: la cuenta que se autenticó, la dirección de origen de la que vino, marcas de tiempo de inicio y fin, la dirección de túnel asignada y los totales de bytes en cada dirección. Es un inventario de sesiones, no una lista de destinos.
Las opciones de registro pueden añadir detalle. Un nivel de verbosidad más alto escribe más sobre el saludo, y un archivo de estado puede listar los clientes conectados, pero ninguno de los dos convierte el servidor en un proxy transparente. Producir URL exige terminar el TLS o ejecutar un proxy explícito, y ambas cosas cambian el acuerdo de confianza en lugar de habilitar una función oculta.
Por eso la versión exacta de la afirmación de que no hay registro de navegación es más estrecha de lo que suena. El servidor no conoce la página, pero sí sabe que existió una sesión y aproximadamente cuántos datos la atravesaron. Si ese registro de sesión se conserva, y durante cuánto tiempo, es una cuestión de política aparte.
Los paquetes internos y los externos son pruebas distintas
Una captura de paquetes es cómo se ve lo que realmente cruza el túnel. En el servidor, nombre la interfaz del túnel y escriba en un archivo que pueda analizarse sin conexión:
sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | headEse archivo contiene tráfico interno descifrado: la dirección de túnel del cliente como origen, la dirección y el puerto de destino, los tamaños de paquete y los tiempos. No contiene la ruta HTTP ni el cuerpo de la respuesta salvo que se haya terminado el TLS en algún punto, y son datos sensibles cuya retención es una decisión de política y no una comodidad de depuración.
Una captura en la interfaz física muestra otra cosa. Allí se ven paquetes externos dirigidos al punto final de la VPN, con la carga cifrada dentro. Las direcciones no relacionadas que aparecen en ese archivo son normales una vez que existe un adaptador virtual, porque el dispositivo de túnel lleva los flujos internos mientras el transporte cifrado lleva los externos.
Pregunte qué debe responder la captura. El uso que hace una aplicación del túnel se ve en el adaptador virtual; el alcance del túnel hasta el punto final se ve en el físico. Usar cualquiera de los dos archivos como si fuera la imagen completa produce conclusiones que los datos no sostienen.
El DNS es donde los nombres se vuelven visibles
El DNS sigue siendo la excepción práctica. El resolutor ve los nombres que se le pide resolver, así que quien lo opera aprende qué sitios consulta un cliente aunque las conexiones posteriores estén cifradas. Una captura del túnel muestra direcciones; el resolutor muestra nombres.
Compruebe qué dirección usó el resolutor para llegar a un servicio externo. La respuesta es la dirección de salida del resolutor, y compararla con la salida de la VPN le dice si la consulta viajó por el túnel:
dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53Si esa dirección coincide con la conexión local y no con la salida del túnel, la consulta evitó la VPN y el nombre era visible en la ruta local. Repita la comprobación tras una actualización del cliente, porque una versión nueva puede cambiar qué resolutor instala el perfil.
El DNS cifrado traslada la visibilidad en lugar de eliminarla. La red ya no ve la consulta, pero el resolutor sí, y la cuestión de confianza simplemente cambia de manos. El nombre del servidor TLS en el saludo de la conexión es otra señal parcial: a menudo sobrevive incluso cuando la carga es opaca, así que las direcciones de destino no son los únicos metadatos que un servidor de reenvío puede observar.
Tres tipos de registros y quién puede leerlos
La contabilidad de sesiones, los registros por nombre y las pruebas de fuga son tres productos distintos con tres obligaciones distintas. Los registros de sesión son baratos y de baja sensibilidad, y responden quién se conectó y cuándo. Los registros por nombre exigen un resolutor que registre o un proxy explícito, y crean una obligación de divulgación hacia las personas afectadas. La prueba de fuga es un test del lado del cliente que compara lo que revela el resolutor con la salida del túnel.
Anote cuál de estos tres ejecuta, quién puede leerlo y cuánto tiempo permanece. Las afirmaciones de que un servicio no guarda registros describen una capa, y solo son ciertas dentro de ese alcance. El mismo proveedor puede ser exacto sobre las sesiones y equivocarse sobre el DNS.
Mantenga la prueba reproducible: la misma consulta al resolutor, la misma interfaz de captura y la misma comparación. Una afirmación de privacidad que no puede probarse en una capa nombrada es un eslogan, no un hecho operativo.