WireGuard envía datos pero no recibe nada de vuelta: ¿qué lado?

Los contadores de transmisión que suben mientras el contador de recepción se queda en cero describen una dirección, no un diagnóstico. La misma lectura aparece cuando el par nunca completó un handshake, cuando el destino eligió el par equivocado, cuando el lado remoto no tiene ruta de vuelta y cuando un filtro descarta la respuesta de camino a casa. Cada uno de esos casos se repara en un lugar distinto.

La comparación que acorta el trabajo está entre una petición que nunca salió del túnel y una respuesta que nunca volvió. Una captura en la interfaz correcta decide entre ambas.

Los contadores describen volumen, no la dirección de la avería

Los contadores de WireGuard registran lo que la interfaz entregó al par y lo que recibió de él. No dicen qué destino, qué par o qué mitad de un intercambio falló. El tráfico de fondo hace que los totales sean aún menos informativos, ya que algunos bytes pueden ser mensajes de mantenimiento o flujos no relacionados. Léalos como un indicio de que la interfaz está activa y luego deje de tratarlos como prueba.

El primer dato útil es si el handshake está vigente. Sin él no se cifró nada para este par y el contador de recepción no tiene motivo para moverse.

Selección del par o camino de la respuesta: dos explicaciones

La primera explicación es que el paquete nunca llegó al par previsto, porque la ruta apuntaba a otro sitio o porque los prefijos permitidos del par no cubrían el destino. La segunda es que el paquete llegó y la respuesta no pudo volver, lo que es un problema de enrutamiento en el extremo remoto. La tabla los separa según lo que observaría en cada punto.

Lea la tabla desde arriba. Un handshake ausente lo envía a las claves, los extremos y el camino exterior, porque todavía no hay nada más que examinar. Un handshake vigente con la petición visible en el servidor traslada el problema a la dirección de vuelta, donde decide la propia tabla de rutas del destino. Una petición que nunca aparece en el servidor es un problema de selección, y los prefijos permitidos en ambos pares son lo primero que hay que comparar.

Dos de esas cuatro filas se reparan en el cliente y dos en el servidor. Saber en qué pareja está es la mayor parte del trabajo.

Dónde desaparecen las respuestas

Una respuesta sale del destino, llega a la interfaz de túnel del servidor y se cifra para el par cuyas direcciones permitidas coinciden con la dirección interna del cliente. Si esa coincidencia falla, la respuesta se descarta en silencio, lo que desde el lado del cliente parece exactamente una avería de red. Si la respuesta está cifrada y el propio filtro del cliente la rechaza, el síntoma vuelve a ser idéntico. Ambos casos necesitan la captura y no el contador.

La versión más fuerte de este error es un servidor que reenvía paquetes para el cliente pero no tiene ruta de vuelta al rango interno del cliente. Acepta la petición, envía la respuesta hacia su puerta de enlace predeterminada y el túnel nunca la ve. Una regla de traducción amplia añadida al servidor oculta esa avería en lugar de reparar la ruta.

Pruebe un solo destino de extremo a extremo

Elija un único destino dentro del rango del par y pruébelo mientras el handshake sea demostrablemente vigente. Los comandos siguientes leen el estado del par, la ruta elegida y ambos lados del intercambio. Ejecute la captura en la interfaz que usan realmente los paquetes cifrados.

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

Una captura que muestra la petición en la interfaz de túnel sin nada de vuelta es una respuesta del lado del servidor, y la tabla de rutas del destino es el siguiente lugar donde mirar. Si no aparece absolutamente nada, el paquete tomó otro camino, así que la ruta local es la sospechosa. Un intercambio visible en ambas capturas sin progreso en la aplicación traslada la pregunta al tamaño del paquete o a un filtro que las estadísticas de la interfaz nunca muestran. Mantenga un destino y un cliente en la prueba, porque una segunda variable convierte la evidencia otra vez en una impresión.

Si los nombres fallan mientras una dirección permitida funciona, la respuesta está en DNS y no en el túnel. Si solo se atascan las transferencias grandes, examine el tamaño del paquete por separado.