Prefijo de host en WireGuard: por qué funciona una dirección y el resto no

El túnel está levantado, el handshake ocurre cada dos minutos y exactamente una dirección del otro lado responde. Los pings a la dirección del túnel del par funcionan; nada detrás de ella lo hace. Alguien lee la configuración de la interfaz, ve un prefijo de host y concluye que la máscara está mal. Ampliarla a un /24 arregla el ping durante un tiempo y luego rompe otra cosa. El prefijo nunca fue el problema, y la ruta que faltaba no es la que controla la máscara.

Qué crea realmente el prefijo de la interfaz

En Linux, asignar una dirección a una interfaz crea una ruta conectada para ese prefijo. Si asignas un prefijo de host, la ruta conectada cubre una sola dirección. Si asignas un /24, cubre 256, y cada una de ellas pasa a considerarse alcanzable por ese enlace.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Un prefijo de host es una elección completamente normal para un túnel punto a punto, porque hay exactamente un par al otro lado. El tercer comando es el que responde a la pregunta del usuario: dice qué interfaz usaría el kernel para ese destino, y no mostrará nada útil si ninguna ruta coincide.

Esa es toda la explicación del síntoma. Una dirección responde porque existe una ruta conectada para ella, o porque la lista permitida del par resulta incluirla. Todo lo demás no tiene ruta y se descarta antes de que WireGuard intervenga. El túnel está sano en todo momento, y por eso el contador de handshakes sigue pareciendo tranquilizador.

AllowedIPs son dos reglas con un solo nombre

La lista permitida por par de WireGuard hace dos trabajos a la vez, y la sintaxis de configuración hace que parezcan uno. De entrada, autoriza qué direcciones de origen puede presentar un par. De salida, selecciona a qué par se envía un paquete, buscando la coincidencia más específica.

Ninguno de los dos trabajos es enrutamiento. El kernel todavía tiene que decidir que un paquete pertenece a la interfaz del túnel antes de que WireGuard lo mire, y esa decisión sale de la tabla de rutas. Una entrada de par con una lista permitida amplia no instala una ruta por sí misma.

Por eso una configuración puede parecer completa y comportarse de forma asimétrica. El cliente envía hacia el otro extremo porque existe una ruta, y las respuestas nunca llegan porque la lista permitida del otro extremo no autoriza el origen del cliente, o porque el otro extremo no tiene ruta de vuelta. Ambas direcciones son decisiones separadas con modos de fallo separados. Anotar cuál estás probando es la mitad del diagnóstico.

De dónde viene la ruta

Si usas wg-quick, las rutas se generan por ti a partir de la lista permitida de cada par, a menos que hayas puesto Table = off y te hayas hecho cargo tú mismo. Ese es el comportamiento que documenta la herramienta, y es la razón por la que una configuración sin directivas de ruta explícitas sigue funcionando.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Compara la lista permitida con las rutas que realmente existen. Un par que permite una subred entera pero produjo solo una ruta de host significa que el ayudante nunca se ejecutó, o que gestionas la interfaz directamente con wg y ip, en cuyo caso nada genera rutas por ti.

Cuando lo gestionas a mano, la ruta es una línea y su forma es explícita: el destino por la interfaz, sin puerta de enlace porque el enlace es punto a punto. Añadirla no es un parche para un prefijo malo; es la mitad que faltaba de un diseño que decidió encargarse del enrutamiento por su cuenta.

Ampliar el prefijo no añade la entrada del par

La solución tentadora es cambiar la dirección a un /24 para que la ruta conectada cubra la LAN del servidor. Parece funcionar, y la razón de que parezca funcionar es que la ruta conectada ahora coincide, no que WireGuard haya aprendido algo nuevo.

Lo que también hiciste fue reclamar todo el rango como directamente alcanzable por ese enlace, incluidas direcciones que pertenecen a otros pares o a una LAN que en realidad está detrás del servidor. El tráfico a esas direcciones ahora entra en el túnel, y si sale por el otro lado depende del enrutamiento y las listas permitidas del propio servidor.

El lado criptográfico no se ve afectado en ningún caso. WireGuard sigue necesitando una entrada en la lista permitida que cubra el destino para elegir un par, y el otro extremo sigue necesitando una entrada que cubra tu origen para aceptarla. Un prefijo de interfaz más amplio no puede proporcionar ninguna de las dos.

Confirma ambas direcciones antes de cambiar nada

Trabaja los dos extremos por separado y anota lo que dice cada uno. En el cliente, la ruta y la entrada del par; en el servidor, la imagen espejo más su propia ruta de vuelta:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

La captura es lo que zanja las discusiones sobre la dirección. Si los paquetes salientes aparecen en la interfaz del túnel y el servidor no registra nada, el extremo remoto los rechaza, normalmente porque tu origen está fuera de su lista permitida. Si no aparece nada en absoluto, falta la ruta o apunta a otro sitio.

Luego arregla el extremo más estrecho. Una entrada en la lista permitida del lado del servidor para la dirección de tu cliente y una entrada en el lado del cliente para la subred de destino es la forma normal, y deja intacto el prefijo de la interfaz. Amplía el prefijo solo si el plan de direcciones realmente quiere una subred compartida en ese enlace, y hazlo como un cambio de plan en lugar de como un paso de depuración.