El cliente dice conectado, el candado está cerrado y, aun así, un sitio registra la dirección de tu piso. Nada ha fallado. Un túnel no sustituye tu Wi-Fi ni tu enlace móvil; coloca un segundo sobre alrededor de determinados paquetes y envía ese sobre por la red que ya tenías. Entender el truco consiste sobre todo en seguir una solicitud y fijarse en dónde se abre el sobre, porque casi todos los síntomas confusos, desde una dirección de casa que se filtra hasta una gran descarga atascada, vienen de esa frontera.

Dos sobres, un enlace físico

Tu portátil mantiene su conexión normal con el router, y el router mantiene su conexión normal con el proveedor. Nada de ese camino cambia cuando se levanta un túnel. Lo que cambia es que determinados paquetes se entregan a una interfaz virtual, se envuelven dentro de un paquete nuevo dirigido al par de VPN y se envían como tráfico ordinario por el enlace físico.

El extremo receptor es un dispositivo que desenvuelve el sobre y reenvía el paquete original hacia su destino. Entre los dos extremos, un observador ve la cabecera exterior y nada de la interior, salvo que el protocolo la cifre, cosa que hacen la mayoría de los protocolos de consumo y que la técnica general no exige.

Por eso la interfaz virtual es a la vez real y engañosa. Existe como objeto del núcleo con una dirección y una unidad máxima de transmisión, y el sistema operativo encamina el tráfico hacia ella como hacia cualquier otra interfaz. No es un cable, y su existencia solo demuestra que hay un componente instalado. Si tu navegador la usa lo deciden las rutas, no que la interfaz esté levantada.

Observa un viaje de una sola solicitud

Elige un destino y pregunta al núcleo qué interfaz usará. Esta única orden resuelve la mayoría de las discusiones sobre si el túnel hace algo:

ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0

Si la salida de la ruta nombra la interfaz del túnel, el paquete se envolverá. Si nombra la interfaz física, no se envolverá, y ningún reinicio del cliente cambia eso. La segunda orden muestra ambas interfaces una junto a otra, y así es como detectas un túnel que se levantó sin dirección o con una dirección de la familia equivocada.

Luego mira el primer salto desde dentro del sobre y compáralo con el primer salto desde fuera:

traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5

Dentro del túnel, el primer salto es la dirección interior del par, no tu router. La captura en la interfaz del túnel muestra los paquetes interiores, que es el tráfico que la aplicación cree que envía. Capturar a la vez en la interfaz física muestra los paquetes exteriores, y las dos cosas juntas son la demostración más clara de lo que hace realmente un túnel.

Tres direcciones, y el sitio solo ve una

La gente las confunde constantemente, y la confusión genera informes de fuga falsos. Son campos distintos en cabeceras distintas con vidas distintas.

AddressWhere it appearsWho can see it
Endpoint addressOuter header, the peer you connect toYour access network and the path to it
Inner tunnel addressInside the envelope, on the virtual interfaceThe peer, and anything the peer routes to
Exit addressSource of the packet that reaches the websiteThe website and its upstream

El número junto al adaptador virtual es la segunda fila. No es la dirección que registra un sitio, y citarlo como tu IP pública es simplemente un error. La dirección que ve un sitio la asigna la salida, y en un túnel de red privada puede no haber ninguna salida pública, porque el destino vive dentro de la organización y no en internet.

Un túnel entre sedes es el mismo mecanismo con otros extremos. Dos routers envuelven tráfico entre redes, y ningún dispositivo individual tiene un cliente instalado. El sobre es idéntico en principio, y la frontera administrativa no.

Dónde se abre el sobre y qué sobrevive a ello

El túnel termina en su par. Si el cifrado propio de la aplicación llega más lejos, sobrevive a esa frontera, que es el caso normal de HTTPS: la sesión del navegador termina en el sitio, así que la salida reenvía texto cifrado que no puede leer.

Nada más sobrevive por defecto. Una solicitud sin cifrar es legible en la salida exactamente como lo era en la Wi-Fi del café, y el túnel no añade una protección que la aplicación nunca tuvo. Del mismo modo, las reglas de cortafuegos y la política de reenvío de la salida deciden qué ocurre después; un apretón de manos correcto es un hecho sobre la conexión con el par, no sobre el resto del viaje.

La sobrecarga es la otra consecuencia visible. Cada paquete lleva una cabecera extra, y el transporte exterior puede añadir la suya, así que la carga útil por paquete se reduce. En un camino con una unidad máxima de transmisión fija, es exactamente por eso por lo que un túnel puede pasar un ping y atascar una carga grande.

Comprueba el camino que la aplicación tomó de verdad

El último paso es confirmar la aplicación concreta, no la máquina en general. Resuelve el destino, mira la ruta para esa dirección y luego observa la conexión mientras está abierta:

getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'

Si la ruta nombra el túnel pero la lista de sockets muestra una conexión con una dirección de origen de la interfaz física, la aplicación está ligada a algo concreto, o un segundo túnel compite por la ruta por defecto. Es una cuestión de enrutamiento, y se puede responder con estas tres salidas en lugar de la pantalla de estado del cliente.

La arquitectura de seguridad RFC 4301 describe la versión de capa IP de este envolvimiento para IPsec, y la misma lógica de capas se aplica a WireGuard y OpenVPN. Una vez que puedes señalar el paquete interior y el paquete exterior como objetos separados, la mayor parte del comportamiento del túnel deja de ser misterioso y se convierte en una tabla de enrutamiento que puedes leer.

Artículos relacionados