WireGuard solo funciona después de que el servidor envíe: conocimiento del extremo

El túnel parece funcionar solo después de que el servidor envíe algo primero. Inicie desde el cliente y no ocurre nada, espere unos segundos, inténtelo de nuevo y lo consigue. El diagnóstico habitual es un NAT roto, y el diagnóstico habitual es erróneo. Lo que cambió es que un par aprendió dónde vive el otro.

Conocimiento del extremo, no accesibilidad

Un par de WireGuard no iniciará un handshake hasta saber adónde enviarlo. La configuración lo aporta como un extremo de dirección y puerto, y el estado en ejecución sigue el extremo en el que cree actualmente.

wg show muestra ambos lados de esa imagen, y un par sin extremo en la salida no puede iniciar nada, por correctas que sean su clave pública y sus prefijos permitidos. Compare la visión del cliente con la del servidor antes de cambiar cualquier regla, porque ambos discrepan a menudo sobre quién sabe qué.

Cómo aprende un par un extremo

WireGuard es deliberadamente silencioso. Cuando un paquete correctamente autenticado llega desde una dirección que el par no esperaba, la implementación actualiza el extremo de ese par a la nueva fuente, y así es como funciona la itinerancia en un portátil que cambia de red. Ese comportamiento explica la dependencia de la dirección: si el servidor envía primero y su paquete llega al cliente, el cliente aprende la dirección actual del servidor y puede responder. Hasta entonces no tiene adónde enviar. El mecanismo es itinerancia autenticada y no un atajo de confianza en el primer uso, porque el paquete tenía que ser válido antes de que el extremo se moviera.

La documentación de las herramientas para wg describe esa actualización, y merece una lectura si va a diseñar en torno a ella.

La traducción con estado añade su propia dirección

Donde el UDP pasa por una puerta de enlace que traduce, la puerta de enlace crea estado para el primer paquete que ve. RFC 4787 describe ese comportamiento y los tiempos de espera que acaban eliminando la asignación. Una asignación inactiva caduca, y un paquete entrante del lado lejano es entonces descartado por la puerta de enlace antes de llegar al equipo. Un túnel que funcionaba toda la mañana deja de responder por la tarde exactamente por este motivo.

Este es un segundo mecanismo independiente que produce el mismo síntoma direccional. Tanto el conocimiento del extremo como el estado de traducción tienen que ser correctos, y arreglar uno no arregla el otro.

Configure la dirección que realmente quiere

Para un cliente que debe iniciar la conexión, ponga el extremo del servidor en la sección de pares del cliente y déjelo ahí. Confiar en que el servidor envíe primero es confiar en un accidente del orden del tráfico que cambiará en una red tranquila. La configuración debería declarar la dirección prevista, no descubrirla.

Para un par detrás de una traducción que debe seguir siendo accesible, active un keepalive persistente en ese lado. Un keepalive cada 25 segundos es el valor inicial habitual, y su propósito es mantener la asignación abierta en lugar de probar el túnel. Elija un solo lado para llevarlo, porque activarlo en ambos duplica el tráfico y el ruido del registro sin mejorar el resultado.

Compare el estado antes y después del desencadenante

Capture las dos vistas en el momento en que falla y luego otra vez después de que el servidor envíe. El primer comando muestra los extremos y la antigüedad del handshake. El segundo muestra si existe una entrada de traducción para el puerto. La captura muestra qué dirección cruzó realmente el cable, y la comprobación de ruta confirma que el cliente no envía ese tráfico a otro lugar por completo.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Anote la columna del extremo y la entrada de traducción juntas. Un par sin extremo y una puerta de enlace sin asignación son dos fallos distintos. Solo uno de ellos se corrige con un keepalive.