¿Pueden las rutas DHCP sacar tu tráfico por fuera del túnel VPN?

El cifrado empieza en una frontera, y esa frontera es una decisión de enrutamiento que toma el punto final antes de que se encapsule cualquier paquete. Una red que nunca ve tus claves puede aun así entregar a tu máquina una ruta que le gusta más que la del propio túnel. Aquí se confunden dos fallos: leer un paquete que ya está dentro del túnel y desviar un paquete que nunca se puso allí.

La distinción importa porque el segundo fallo es más barato de montar y mucho más fácil de pasar por alto. Se manifiesta como una petición que salió por la interfaz equivocada mientras el cliente seguía informando de una conexión sana.

Dos formas en que una red puede afectarte

Un paquete que llega al túnel tiene su carga útil oculta para cada salto que cruza, y esa protección se mantiene incluso cuando el camino te sorprende. Un paquete que nunca llega al túnel es una petición corriente desde tu dirección, enviada adonde apuntaba la tabla de rutas. El primer fallo necesita un cifrado roto o un par comprometido, mientras que el segundo solo necesita un mensaje de configuración en el que tu máquina decidió confiar. Esa asimetría es la razón por la que la mitad del enrutamiento merece su propia revisión.

El equipo que está en el camino no necesita tus claves para influir en el segundo caso. Solo necesita que tu punto final acepte una ruta, un resolutor o una regla de política que produzca una.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

De dónde puede venir una ruta antes de que exista el túnel

DHCP reparte más que una concesión de dirección. La opción de ruta estática sin clases puede llevar prefijos de destino y saltos siguientes, y RFC 3442 analiza las consecuencias de seguridad de una dirección de enrutador equivocada: tráfico desviado, una denegación de servicio o un observador apostado en el camino. Un cliente que acepta esas rutas antes de que el túnel esté levantado puede acabar con un camino preferido que no tiene nada que ver con tu proveedor.

Nada de eso hace universal la inyección de rutas. El cliente tiene que aceptar la opción, el prefijo tiene que cubrir el tráfico que te importa, el siguiente salto elegido tiene que ser alcanzable y la política de aplicación tiene que permitir que el paquete salga por ese camino. Quita cualquiera de ellas y la misma respuesta es inocua. Por eso también dos máquinas en una misma red pueden comportarse de forma distinta, ya que no ejecutan el mismo cliente, la misma política ni siquiera la misma familia de direcciones.

IPv6 merece su propia pasada, porque los anuncios de enrutador llevan una ruta por defecto mediante un código distinto al de la opción DHCPv4. Una prueba que solo inspecciona la tabla v4 no lo ha cubierto.

Comprueba el camino que el núcleo elige de verdad

Las consultas de ruta se pueden responder, así que pregúntales en lugar de deducirlo de una luz de estado. Los comandos de abajo muestran la ruta y la fuente elegidas para un destino, además de las reglas que pueden prevalecer sobre la tabla principal. Ejecútalos mientras estás conectado y otra vez tras reconectar, porque una renovación de la concesión puede cambiar la respuesta.

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

Lee la salida buscando dos cosas: la interfaz nombrada en la ruta y la dirección de origen elegida. Una ruta de túnel nombra el dispositivo de túnel, una ruta filtrada nombra el físico, y la diferencia se ve sin descifrar nada. Si la respuesta cambia entre ejecuciones, guarda ambas salidas y compara las reglas que las produjeron.

No te detengas en la ruta por defecto. Una excepción de aplicación, un prefijo de túnel dividido o una segunda regla de política pueden llevar un destino concreto por alrededor del túnel mientras la ruta por defecto sigue apuntando dentro.

Decide dónde debe vivir la aplicación

Tres condiciones deciden si la aplicación en el lado del cliente basta o si necesitas algo fuera de él. Si el cliente instala y defiende rutas para cada familia de direcciones que usas, un túnel que posee la ruta por defecto suele ser suficiente. Si la máquina tiene que llegar a recursos locales mientras todo lo demás se queda dentro del túnel, esas excepciones deben enumerarse y poseerse en lugar de dejarlas a lo que anuncie la red de acceso. Y si la plataforma puede ligar el tráfico a una interfaz por aplicación, esa ligadura es una garantía más fuerte que una ruta que cualquier cosa puede prevalecer.

Elijas lo que elijas, escribe la decisión donde vive la configuración. Una regla que existe porque alguien la tecleó durante un incidente no sobrevivirá al siguiente reinicio, así que mantén estrechas las excepciones locales y de arranque y anota por qué existe cada una.

Vuelve a ejecutar los comandos de consulta después de cada actualización del cliente y de cada cambio de red, y compáralo con la última salida registrada. La tabla de rutas es la frontera de aplicación, así que trátala como tal.