Una app por WireGuard: enlazar no es enrutar

El ajuste parece un interruptor por aplicación, así que la gente enlaza el cliente a la interfaz WireGuard y espera que solo ese cliente use el túnel. Lo que hace en realidad el enlace es elegir una dirección de origen. Luego el núcleo busca una ruta para el destino, encuentra la ruta predeterminada normal y envía el paquete por el enlace físico con la dirección del túnel adjunta. Solo una ruta seleccionada para esa dirección de origen completa la intención.

El mecanismo tiene dos mitades: una tabla de enrutamiento que solo debería usar el tráfico del túnel, y una regla que envía allí el origen correspondiente.

Enlazar fija una dirección de origen y nada más

Linux elige una interfaz de salida buscando el destino en una tabla de enrutamiento, después de que las reglas de política hayan tenido ocasión de redirigir esa búsqueda. Las reglas pueden seleccionar por la dirección de origen, una marca de cortafuegos, la interfaz de entrada, un UID o incluso un puerto; cada una es otra forma de decir este tráfico en lugar de todo. La configuración del cliente VPN elige la tabla que contiene las rutas del túnel; la regla elige qué tráfico puede consultarla. El enlace por sí solo no aporta ninguna de las dos.

Por eso el fallo parece tan extraño. La aplicación sin duda usa la dirección del túnel, el túnel sin duda está levantado y el tráfico sin duda sale por la interfaz equivocada. Cada afirmación es cierta, y juntas describen un sistema donde nada conectaba la dirección con la ruta.

Dale al túnel su propia tabla

wg-quick instala las rutas donde el perfil le dice. Añadir Table = 40 bajo [Interface] las traslada a la tabla 40 en lugar de la tabla principal. Levanta la interfaz y confirma que llegaron: ip -4 route ls table 40 debería mostrar las rutas del túnel, y ip -4 route get 10.66.127.142 muestra cómo resuelve el núcleo una de ellas ahora mismo. Con las rutas en su propia tabla, la tabla principal sigue funcionando para todo lo demás.

Haz lo mismo para IPv6 en lugar de hacer coincidir un prefijo amplio. ip -6 rule add from fd00::2/128 lookup 40 fija una dirección; fc00::/8 puede chocar con otras interfaces del equipo y producir una regla que coincide con más de lo previsto.

Añade la regla de origen y vigila los contadores

Después conecta las mitades: ip -4 rule add from 10.66.127.142/32 lookup 40, con esa misma dirección adjunta a la interfaz WireGuard. Pon las dos reglas en PostUp para que una reconexión las restaure. Verifícalo con una petición real y no con un ajuste: ip route get 1.1.1.1 from 10.66.127.142 debería nombrar el dispositivo del túnel, y curl --interface wg0 ifconfig.me debería informar de la dirección del túnel en lugar de la de casa.

Cuando sigue fallando, lee ip -s rule. Una regla que existe pero que nunca coincidió muestra contadores a cero, y eso distingue una regla equivocada de la ausencia total de regla. Ese único comando ahorra muchas conjeturas sobre si la aplicación ignoró su ajuste de interfaz.

El caso inverso: mantén SSH fuera del túnel

El problema opuesto es igual de común: wg-quick posee la ruta predeterminada y la sesión SSH al servidor muere a mitad de sesión. Sus reglas están en un número de prioridad bajo, así que una excepción debe evaluarse antes que ellas. ip rule add dport 22 ipproto tcp table main priority 123 hace eso en un iproute2 reciente; donde el selector no está disponible, marca el flujo en nftables y haz coincidir la marca.

Comprueba también el camino de respuesta. Una sesión SSH que se establece y luego se queda callada suele tener enrutamiento asimétrico, con una dirección saliendo por el túnel y la otra por la interfaz física. ip route get para la dirección del servidor te dice por dónde iría la respuesta.

Anota el número de tabla, la regla de origen y la excepción en el propio perfil. Las tres pertenecen a un mismo diseño y se editarán juntas.