WireGuard: dos medias rutas frente a 0.0.0.0/0 en wg-quick

Dos prefijos /1 cubren exactamente las mismas direcciones IPv4 que un solo /0, y esa igualdad solo se cumple dentro de la lista de prefijos permitidos del peer. Deja de cumplirse en el momento en que la herramienta de configuración decide cómo enrutar, porque Linux wg-quick trata un prefijo por defecto como un caso especial y no como aritmética. La rama especial instala una tabla dedicada, dos reglas de política, una marca de socket y ajustes de ruta inversa que un par de medias rutas nunca recibe. Así que cuando un proxy o un navegador deja de funcionar tras la edición, los prefijos son la parte menos interesante del cambio.

La lista de prefijos no es toda la configuración

AllowedIPs hace dos trabajos a la vez, y solo uno de ellos trata de la cobertura. Para el propio WireGuard la lista es enrutamiento por clave criptográfica: decide qué destinos se cifran hacia un peer y qué direcciones de origen puede usar ese peer. Para wg-quick la misma lista también actúa como especificación de rutas, y la ruta que produce depende de qué rama coincida con la lista. Una cobertura idéntica con dos formas de lista distintas no dice nada, por tanto, sobre un estado de host idéntico.

La configuración por defecto le quita esa decisión de las manos, porque Table es automática de forma predeterminada y la herramienta elige dónde acaban las rutas. Otro gestor de red, un envoltorio de distribución o un valor personalizado de Table vuelve a cambiar el resultado, y por eso un consejo escrito para un host puede parecer erróneo en el siguiente.

Qué añade la rama por defecto más allá de una ruta

Una entrada /0 envía wg-quick por su ruta por defecto: una tabla de enrutamiento separada recibe la ruta por defecto, una regla de política manda allí el tráfico sin marcar, una segunda regla mantiene como autoritativas las rutas más específicas de la tabla principal, y la interfaz recibe una marca de cortafuegos aplicada a su propio socket. Esa marca es el guardián del bucle. Los datagramas cifrados que llevan el tráfico del túnel salen con la marca puesta, de modo que la regla que dirige todo lo demás al túnel no se traga los paquetes de transporte del propio túnel.

Un par de entradas /1 toma en cambio la ruta ordinaria. Dos rutas acaban en la tabla configurada, y no aparece nada de la maquinaria que las rodea, no porque sea innecesaria sino porque esa ruta de código nunca se ejecutó.

Dónde divergen los dos arreglos

La divergencia se muestra primero como recursión. Con las medias rutas en la tabla principal, la dirección de transporte del propio peer cae dentro de un prefijo del túnel, así que el paquete que debería portar el túnel coincide con una ruta que apunta hacia dentro del túnel. Algo tiene que eximirlo: una ruta de host para el extremo actual, una marca aplicada a mano o una regla específica de la interfaz. Una ruta de host funciona hasta que cambia la dirección del extremo, algo que ocurre con extremos basados en DNS, clientes itinerantes y configuraciones con varios peers.

En segundo lugar, todo lo que razona sobre marcas cambia de comportamiento. Un proxy transparente que redirige conexiones localmente crea sockets nuevos cuyas marcas y orígenes difieren del flujo original del cliente, y las reglas de política que genera la rama por defecto eran parte de lo que separó esos flujos. Leer la conexión saliente del propio proxy es un ejercicio distinto de comprobar si el destino original es alcanzable.

Lea las reglas y las marcas antes de editar

Capture el estado actual mientras el túnel está sano y otra vez después del cambio, y compare los dos volcados en lugar de razonar a partir del archivo de configuración. Incluya las reglas de política, cada tabla, la marca de la interfaz y los extremos registrados.

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

Si la primera línea de salida ha perdido la regla del tráfico sin marcar y la tabla dedicada está vacía, la rama por defecto no se ejecuta y ninguna aritmética de prefijos restaurará sus efectos. Una marca de cero en una interfaz que antes llevaba una es la misma señal, visible en un solo valor.

Ensayad la pérdida del túnel antes de desplegar

Si la disposición de medias rutas es la elección deliberada, debe aportar explícitamente las piezas que faltan: una ruta de extremo que sobreviva a los cambios de dirección, el comportamiento previsto cuando el túnel cae y el tratamiento equivalente para IPv6. Anotadlo como requisitos en lugar de descubrirlo durante una caída. Después ensayad el fallo, porque un túnel completo que recae en silencio sobre el enlace físico es peor que uno que deja de funcionar.

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

La consulta de ruta debería resolver el extremo por la interfaz física sin atravesar el túnel, y bajar la interfaz debería dejar el host en el estado que prometió el diseño. Un proxy que funciona tras la sustitución demuestra que el estado de host generado importaba; no demuestra que la prevención de bucles y el comportamiento en estado bajado hayan sobrevivido a la edición.