WireGuard AllowedIPs: la ruta que NetworkManager nunca añadió

El contador de handshake se actualiza, la interfaz conserva su dirección y un ping al otro lado no llega a ninguna parte. Esa combinación desconcierta porque un handshake que funciona parece la prueba de que el túnel está listo. No lo es: un túnel puede estar completamente negociado y aun así no tener ninguna ruta que dirija el tráfico hacia él, y son dos tareas separadas que realizan dos piezas de estado separadas. La solución depende por completo de cuál de las dos falta, así que el primer paso es averiguarlo.

wg-quick hace ambas cosas sin que nadie se lo pida. El soporte de WireGuard integrado en NetworkManager también instala rutas de peers de forma predeterminada, lo que reduce los sospechosos a una opción desactivada, otra tabla de enrutamiento o una configuración importada por otra vía.

Confirme el túnel antes de perseguir la ruta

wg show muestra la interfaz, el peer, el extremo y la antigüedad del último handshake, y ip addr show confirma que la dirección está presente. Un handshake reciente significa que las claves, el extremo y la ruta UDP funcionan. Todo lo que está roto queda aguas abajo: enrutamiento, filtrado o resolución de nombres.

Luego pregunte al núcleo qué haría con un destino real en lugar de uno hipotético: ip route get 10.42.7.9. La respuesta nombra la interfaz de salida y la dirección de origen que llevaría el paquete. Cuando nombra el adaptador físico, el paquete nunca entra en el túnel por muy sano que parezca el handshake.

AllowedIPs es un filtro y una lista de rutas

Los prefijos de AllowedIPs hacen dos trabajos. Seleccionan qué peer transporta un destino de salida y validan la dirección de origen de los paquetes entrantes, que es el límite del enrutamiento por clave criptográfica. En wg-quick además impulsan la instalación automática de rutas, y ese comportamiento extra es la razón por la que la misma configuración funciona desde una terminal y no desde un cliente de escritorio.

En el caso que hay detrás de este artículo, el perfil se importó mediante un complemento de terceros y no con el soporte integrado, y la interfaz subió sin la ruta del prefijo. Listar la tabla lo muestra de inmediato: ip route show solo contiene la ruta conectada de la dirección de la interfaz y nada para el rango remoto.

Pregunte si las rutas de peers están activadas

Lea el ajuste antes de modificar nada: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Cuando peer-routes muestra no, la reparación admitida es nmcli connection modify work-wg wireguard.peer-routes yes, seguida de una reconexión. Añadir en su lugar una ruta estática funciona hasta la siguiente activación y luego desaparece en silencio. Esa desaparición es la pista: una ruta que vuelve como un misterio cada mañana no la instala el perfil.

Si la opción ya está activada, compruebe si el prefijo vive en otra tabla con ip route show table all | grep 10. Una ruta en una tabla que no es la principal no falta, simplemente es invisible para una consulta que solo mira la tabla principal. Arregle el enrutamiento por políticas en lugar de apilar una entrada duplicada encima.

Añada el prefijo a la conexión, no al sistema en marcha

En el editor de conexiones, la página de WireGuard contiene el peer y sus AllowedIPs, y la página de IPv4 contiene rutas adicionales. Una ruta añadida allí sobrevive a las reconexiones porque pertenece al perfil. En la línea de comandos el equivalente es añadir una ruta a la conexión con la forma de puerta de enlace vacía y luego bajar y subir la conexión para que el cambio se aplique.

Elija el prefijo más estrecho que cubra los equipos que necesita. Copiar el ejemplo /8 del proveedor puede tragarse rangos locales que estén dentro por casualidad, y los fallos resultantes parecen un túnel roto más que una ruta demasiado amplia.

El túnel dividido lo decide la lista de prefijos

No hay ningún interruptor de túnel dividido; la lista de prefijos es la decisión. Un peer con un rango para la LAN de la oficina y otro para una red de laboratorio envía exactamente esos destinos por el túnel y deja todo lo demás en paz. Un solo equipo necesita un /32, y los rangos que se solapan en dos sitios necesitan prefijos de equipo hasta que alguien renumere una subred.

Elegir no enviar nada por el túnel lleva la misma decisión a su límite: una lista mínima mantiene el enlace arriba mientras el tráfico corriente sigue su camino habitual. Escriba la intención, porque si no el siguiente lector tomará la lista corta por un descuido y la ampliará con buena voluntad.

Un solo dueño para la tabla de rutas

wg-quick y NetworkManager creen ambos que son dueños de las rutas de la interfaz. Importe una configuración escrita para wg-quick y luego arranque también el servicio wg-quick, y obtendrá entradas duplicadas o en conflicto cuyo comportamiento depende de cuál se ejecutó al final. Elija un único dueño y elimine el otro: si NetworkManager gestiona la conexión, desactive la unidad wg-quick para esa interfaz y no añada nunca un segundo perfil para el mismo dispositivo.

Cuando la división debe seguir a un adaptador físico en lugar de a un destino, ha pasado al enrutamiento por políticas, y el enrutamiento por políticas también necesita un solo autor. Verifique repitiendo ip route get y luego llegando a un equipo dentro del prefijo remoto con algo que imprima la dirección de origen que eligió. Compruebe IPv6 y DNS por separado si el perfil lleva alguno de los dos.