Dos peers de WireGuard comparten un rango: cuál recibe el paquete

Dos peers enumeran rangos que se tocan, y el tráfico llega al equivocado. Nada está corrupto: WireGuard elige un peer haciendo coincidir el destino con los rangos configurados, y gana la coincidencia más específica. Antes de ampliar cualquier cosa, decide qué peer debería poseer qué prefijo.

El prefijo más largo gana dentro de WireGuard

Cada entrada de peer lleva un conjunto de prefijos de destino. Cuando un paquete se enruta hacia la interfaz, la implementación busca la entrada con el prefijo coincidente más específico, la misma regla que aplica una tabla de enrutamiento. Por eso un /24 vence a un /16 que lo contiene, y el peer más estrecho recibe el tráfico.

Las configuraciones road-warrior lo usan deliberadamente. Un peer posee un rango amplio para un sitio, y los hosts individuales se recortan con entradas /32 que pertenecen a otros peers. El patrón funciona porque los recortes son más específicos, no por el orden.

Anota la propiedad como una tabla de prefijo y peer. Si dos entradas describen el mismo prefijo, la configuración ya no expresa una intención, expresa una carrera.

El sistema operativo elige primero la interfaz

WireGuard solo elige entre los peers de una interfaz. Qué interfaz recibe el paquete se decide antes, por la tabla de enrutamiento del host, y una segunda ruta predeterminada o una ruta obsoleta puede enviar el tráfico a un lugar donde la lista de peers nunca lo ve. Por eso un diagnóstico a nivel de peer puede ser correcto y aun así no explicar el fallo. Revisa la ruta hacia el destino antes de leer la configuración del peer, porque una ruta que apunta a la interfaz física omite toda la cuestión.

La herramienta suele instalar esas rutas a partir de los rangos de los peers, lo que significa que un cambio en la lista de un peer puede redirigir en silencio tráfico que antes pertenecía a otro. Editar un peer es, por tanto, un cambio de enrutamiento disfrazado. Revisa ambos a la vez, o arreglarás uno y romperás el otro.

Los paquetes entrantes se comprueban por origen

La lista de rangos cumple una doble función. Para el tráfico saliente elige un peer por destino, y para el tráfico entrante autoriza una dirección de origen. Un paquete que llega desde una dirección fuera de los rangos de ese peer se descarta antes de que lo vea cualquier firewall.

Esa asimetría es fácil de pasar por alto cuando se lee un lado de la configuración. Un peer que puede alcanzar una subred no queda por ello autorizado a enviar desde esa subred, y las dos direcciones se aplican con comprobaciones distintas.

La propiedad estrecha del origen convierte esto en una ventaja. Da a cada peer un /32 para su propia dirección y el firewall posterior tendrá un origen fiable con el que coincidir, en lugar de un rango de todo el grupo que cualquier miembro podría reclamar.

Los rangos duplicados no son failover

Asignar el mismo prefijo a dos peers no crea un balanceador de carga ni una ruta de reserva. No hay comprobación de estado ni afinidad de sesión: la entrada ganadora la decide el orden interno de la implementación, que no es un contrato sobre el que debas diseñar. Si necesitas salidas alternativas, exprésalas donde se define la selección. Una política de enrutamiento, una métrica o un par de prefijos distintos con un propietario documentado cada uno producen un comportamiento que puedes predecir y probar.

Ampliar un rango para arreglar un fallo no relacionado es el otro error habitual. Aleja el tráfico del peer que funcionaba, y el nuevo síntoma llega antes de que se entienda el antiguo.

Verifica la selección antes de editar

Tres comandos responden a las tres preguntas en orden. El primero enumera los rangos que reclama cada peer. El segundo muestra qué interfaz usaría el host para un destino. El tercero muestra el estado vivo de los peers después de que haya fluido el tráfico.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Ejecútalos antes y después de un cambio y compara. Si la salida de la ruta cambió pero el tráfico sigue llegando al peer equivocado, las listas de prefijos se superponen de una forma que aún no has documentado. Si la salida de la ruta no cambió, la configuración del peer nunca fue lo que se consultaba.

Registra el destino, la interfaz elegida y el peer elegido en el ticket. Ese trío es lo que hace revisable más tarde una superposición, y es mucho más útil que una captura de pantalla de la configuración.