Encadenar dos VPN: qué oculta y cuánto cuesta

Dos túneles anidados no te hacen anónimo. Lo que hacen es repartir las observaciones entre dos proveedores, así que ninguno ve juntos tu dirección de casa y tu destino. Es un beneficio real pero estrecho, y llega con problemas de enrutamiento, DNS y MTU que aparecen la primera vez que dependes de él.

1. Decide para qué sirve el segundo salto

Escribe el objetivo en una sola frase antes de configurar nada. Si es que tu ISP no puede ver qué sitios visitas, un túnel lo consigue. Si es que ningún proveedor puede vincular tu dirección con tu tráfico, dos lo consiguen. Si es que nadie puede identificarte, ningún número de saltos llega ahí.

La cadena es tan fuerte como los registros del proveedor más débil y las cuentas que ambos guardan. Los pagos, el correo de registro y la telemetría de la aplicación quedan por completo fuera del túnel.

2. Haz que el extremo interior sea alcanzable a través del túnel exterior

El fallo habitual es que el túnel interior nunca se establece. Una conexión exterior de túnel completo posee la ruta por defecto, así que el intento del cliente interior de llegar a su propio extremo queda tragado por el túnel exterior y se descarta o entra en bucle. El extremo interior necesita una ruta explícita por la interfaz exterior, instalada antes de que arranque el cliente interior. Si no, el handshake compite con la ruta y pierde.

WireGuard muestra el mismo conflicto desde la otra dirección. Los AllowedIPs de cada peer deciden qué destinos entran en ese túnel, así que una interfaz interior que reclama todas las direcciones también reclama el extremo exterior, salvo que gane una ruta más específica. Solapar AllowedIPs entre dos interfaces es una configuración en la que un lado pierde en silencio.

El encadenamiento de contenedores hace explícita la separación y obvia la trampa. Un contenedor con su propio espacio de nombres, su propia ruta por defecto y un cliente dentro reenvía lo que el host le envía; el host no empieza a usar ese camino por sí solo. Activa el reenvío, añade una ruta para el túnel del contenedor y apunta el servicio a la dirección del contenedor.

3. Mantén el DNS en el mismo camino

El DNS tiene que viajar por donde viaja el tráfico. Si el proveedor interior empuja resolutores y el host sigue consultando los locales, esas consultas revelan exactamente los sitios que el túnel debía ocultar. Compruébalo con una captura en cada interfaz de túnel en vez de fiarte del panel de estado del cliente. Una fuga aquí es invisible durante la navegación normal y evidente en una captura.

Los diseños de DNS dividido lo dificultan, porque una consulta de un nombre local puede pertenecer legítimamente fuera del túnel. Escribe la lista de excepciones a propósito en lugar de descubrirla según qué resolutor respondió.

4. Ajusta el MTU antes de que los usuarios lo descubran por ti

El MTU es la otra víctima previsible. Dos encapsulaciones restan dos cabeceras, y un túnel exterior que ya bajó el MTU de la ruta deja menos espacio dentro. Los síntomas son conocidos: las peticiones pequeñas pasan, las transferencias grandes y los handshakes TLS se atascan.

ip link set dev wg1 mtu 1280 es la solución contundente, y limitar el MSS en el reenviador es la más pulida. Reintentar la conexión no es solución alguna.

5. Prueba el fallo que de verdad vas a tener

Rompe el túnel exterior a propósito y observa qué pasa. Una cadena que cae en silencio a un camino directo cuando muere el salto exterior es peor que no tener cadena, porque filtra justo en el momento en que creías estar cubierto. El comportamiento deseable es un kill switch que detenga todo el tráfico. Anota el resultado, porque no querrás redescubrirlo en mitad de un incidente.

La latencia y un segundo punto de fallo son el coste permanente. Dos saltos también significan dos colas de soporte cuando algo se rompe a una hora incómoda.