Entendiendo VPNs Parte 3

Parte 3 de 4…¿o 5?

Esta parte trata sobre cómo las redes corporativas o de censura usan inspección profunda de paquetes (DPI) para detectar y bloquear tráfico VPN, y cómo ocultar el hecho de que estás usando una VPN.

La siguiente parte será más práctica con casos de uso, dispositivos y configuraciones específicas para evadir la censura.

La configuración y los ejemplos aquí son de Mullvad VPN (WireGuard) con Fedora Linux. En el futuro, agregaré ejemplos usando distros basadas en Debian.

Fugas de DNS

Instalaste Mullvad y la VPN está funcionando, todo parece bien. ¿O no?

Incluso si tienes tu VPN activa y funcionando, una fuga de DNS puede deshacer silenciosamente la privacidad que crees tener.

Una fuga de DNS ocurre cuando las consultas DNS de tu dispositivo evitan el túnel VPN y se envían a tu ISP u otros servidores DNS de terceros, exponiendo potencialmente los sitios web que visitas. Tu tráfico está cifrado, tu IP está oculta, pero tus consultas DNS siguen mapeando toda tu sesión de navegación en los registros de tu ISP.

Cuando visitas un sitio web, tu dispositivo primero resuelve el nombre de dominio en una dirección IP. Esa resolución es una consulta DNS, y necesita ir a algún lugar. Una VPN correctamente configurada envía esas consultas a través de la interfaz cifrada y las resuelve en los servidores DNS del proveedor de VPN. Tu ISP nunca debería ver qué dominios estás consultando.

Por Qué Ocurren las Fugas de DNS

Culpable 1: systemd-resolved

En Linux, el culpable suele ser systemd-resolved mal configurado para la interfaz VPN.

systemd-resolved es un servicio del sistema integrado en la mayoría de las distros Linux modernas que actúa como un resolver DNS centralizado para todo el sistema operativo. En lugar de que cada aplicación haga sus propias consultas DNS directamente, todas pasan por systemd-resolved.

Cuando la app de Mullvad se conecta, registra su servidor DNS (10.64.0.1) y el dominio de enrutamiento ~. con systemd-resolved (básicamente diciéndole: “para todas las búsquedas de dominio, usa esta interfaz”). Si ese registro no ocurre correctamente, systemd-resolved recurre al DNS que obtuvo por DHCP, que típicamente es tu router, que típicamente es tu ISP.

Compruébalo:

resolvectl status

# Bajo la interfaz wg0-mullvad, quieres ver:
# Current DNS Server: 10.64.0.1
# DNS Domain: ~.

Si ves ~. bajo la interfaz VPN, todas las consultas DNS se enrutan ahí. Si no, tienes una fuga.

Incluso sin fugas, tú controlas qué resolver DNS maneja tus consultas dentro del túnel. Mullvad usa por defecto su propio resolver (10.64.0.1), pero podrías tenerlo configurado con uno personalizado como Cloudflare. Ambos se enrutan a través de la VPN, así que tu ISP no ve nada en ningún caso; la única diferencia es qué tercero resuelve tus dominios. Cloudflare es más rápido y está distribuido globalmente, pero es una empresa comercial con sede en EE.UU. El resolver de Mullvad es sin registros, con sede en Suecia, y ya está dentro de tu perímetro de confianza ya que tu tráfico pasa por ellos de todos modos. Puedes cambiar y verificar con:

# Comprueba tu configuración actual
mullvad dns get

# Cambia al resolver de Mullvad
mullvad dns set default

# Usa el resolver DNS de Cloudflare
mullvad dns set custom 1.1.1.1 1.0.0.1

# Verifica qué resolver ve Mullvad (vacío = DNS personalizado)
curl https://am.i.mullvad.net/dns

# Comprobación completa de conexión: IP, DNS, estado de VPN
curl https://am.i.mullvad.net/json

Culpable 2: Configuración del Navegador

El segundo culpable común es tu navegador. Tanto Chrome como Firefox soportan DoH (DNS-over-HTTPS), que permite al navegador manejar la resolución DNS completamente por su cuenta, evitando el resolver del sistema.

El Secure DNS de Chrome funciona en modo automático por defecto: intenta actualizar tu proveedor DNS configurado en el sistema a DoH si ese proveedor está en su lista conocida (Google, Cloudflare, NextDNS, etc.). Si tu sistema operativo ya apunta a Google DNS, Chrome resolverá vía 8.8.8.8 sobre DoH (fuera del túnel VPN). Firefox usa Cloudflare DoH por defecto. En cualquier caso, ninguno pasa por tu VPN por defecto.

Para prevenir fugas, desactiva DoH en tu navegador por completo, o apúntalo al endpoint DoH de tu proveedor de VPN. Mullvad tiene dns.mullvad.net, que bloquea anuncios, no guarda registros y está disponible sobre DoH/DoT.

Prueba externamente en dnsleaktest.com. Si los servidores de tu ISP aparecen en los resultados, tienes una fuga, y necesitas arreglarla.

El diagrama de abajo muestra los 2 caminos que pueden tomar las consultas DNS:

Cómo las Redes Saben que Estás Usando una VPN

Los equipos de IT usan firewalls con Deep Packet Inspection (DPI) que inspeccionan paquetes y analizan el contenido, estructura y temporización del tráfico para identificar protocolos por su huella.

El problema aquí es que WireGuard tiene una huella fácil de identificar. El mensaje de inicio de handshake de WireGuard es exactamente de 148 bytes y la respuesta es de 92 bytes. Estas son constantes definidas en la especificación de WireGuard. Más allá del handshake, el tráfico de WireGuard tiene patrones consistentes: siempre es UDP, los intervalos de keepalive ocurren cada 25 segundos por defecto, y la distribución de payload tiene una estructura particular. Cualquier sistema DPI con una regla para WireGuard puede identificar esta huella al instante y marcarla.

Esto importa en 3 escenarios:

1. Redes Corporativas Con Firewalls de Nueva Generación: Palo Alto y firewalls DPI similares tienen firmas de WireGuard en sus conjuntos de reglas. Un equipo de IT puede bloquear fácilmente WireGuard (o cualquier protocolo VPN) con una sola regla.
2. Países Restrictivos: Países con restricciones de red dependen de sistemas DPI para identificar y bloquear tráfico VPN. El propio Mullvad señala que WireGuard está bloqueado en China.
3. Throttling del ISP: Algunos ISPs ralentizan el tráfico VPN basándose en la identificación del protocolo sin bloquearlo completamente. Por ejemplo, tu VPN funciona pero se vuelve lenta después de cierto umbral de datos.

Ocultando el Hecho de que Estás Usando una VPN

La ofuscación no está integrada en WireGuard, así que debes agregar una capa de ofuscación encima.

Por ejemplo, Mullvad proporciona estos métodos de ofuscación (anti-censura) para evadir restricciones DPI:

• Shadowsocks envuelve el tráfico WireGuard dentro de un flujo proxy ofuscado. El tráfico resultante parece bytes cifrados aleatorios sin firma de protocolo identificable (sin headers de handshake de WireGuard, sin puerto consistente, sin comportamiento exclusivamente UDP). Para un sistema DPI, es indistinguible de TLS o cualquier otro flujo cifrado.
• udp2tcp envuelve paquetes UDP de WireGuard dentro de un flujo TCP. Útil en redes que bloquean UDP por completo. La contrapartida es el rendimiento ya que pierdes la velocidad de UDP. Úsalo cuando lo necesites, no como configuración por defecto.
• QUIC tuneliza WireGuard dentro de frames QUIC (otro transporte de ofuscación que es más difícil de identificar que UDP puro y más difícil de bloquear que los transportes basados en TCP).
• LWO (Lightweight Obfuscation) es la opción con menor sobrecarga, con transformación mínima de paquetes, sin capa proxy. Puedes usar esto en entornos donde WireGuard plano se bloquea pero Shadowsocks completo parece excesivo.
• Cambio de puerto de WireGuard es el más ligero de todos. Algunas redes bloquean el puerto por defecto de WireGuard (51820/UDP) pero dejan otros puertos UDP abiertos. wireguard-port te permite cambiar a un puerto diferente sin sobrecarga de ofuscación (útil cuando el problema es un simple bloqueo de puerto en vez de DPI real).
• Modo auto deja que la app pruebe métodos en orden de sobrecarga hasta que uno conecte. Útil si no sabes exactamente qué está bloqueando la red y no quieres adivinar manualmente.

# Comprueba el estado actual de anti-censura
mullvad status

# Lista completa de modos disponibles: auto, off, wireguard-port, udp2tcp, shadowsocks, quic, lwo
mullvad anti-censorship set mode auto          # deja que la app lo descifre
mullvad anti-censorship set mode shadowsocks   # mejor evasión de DPI
mullvad anti-censorship set mode udp2tcp       # para redes que bloquean UDP
mullvad anti-censorship set mode quic          # WireGuard sobre QUIC/HTTP3
mullvad anti-censorship set mode lwo           # ofuscación ligera de headers
mullvad anti-censorship set mode off           # volver a WireGuard plano

# Establece el puerto de WireGuard a uno diferente
mullvad anti-censorship set wireguard-port 4440

# Cada método tiene su propio subcomando para configuración avanzada por método
mullvad anti-censorship set shadowsocks --help
mullvad anti-censorship set udp2tcp --help

Mullvad también tiene una función llamada DAITA (Defense Against AI-guided Traffic Analysis), que en lugar de evadir DPI, combate el análisis de tráfico usando machine learning. Agrega datos ficticios aleatorios al tráfico VPN para evitar que los sistemas reconozcan el tráfico VPN al correlacionar la temporización, tamaño y patrones de los paquetes.

Así se ve usando el método de ofuscación shadowsocks en una red con censura:

Que Sigue?

Este es un buen punto de parada para la siguiente parte que será más práctica con diferentes casos de uso. Planeo hacer algunas configuraciones específicas y dispositivos así que tomará más tiempo.

Partes Anteriores:

• Parte 1: Entendiendo VPNs Parte 1.
• Parte 2: Entendiendo VPNs Parte 2.