El saludo de WireGuard se completa, pero no vuelve ninguna respuesta

Los saludos recientes son una buena noticia y una afirmación mucho más modesta que la frase que uno querría escribir. Los pares intercambiaron mensajes de saludo autenticados. Un paquete de aplicación todavía tiene que llegar a su destino interno y volver.

Esa brecha entre un plano de control sano y un plano de datos silencioso es todo el tema aquí. Dos lecturas de los mismos contadores le dicen de qué lado está.

Un saludo demuestra claves, no entrega

El saludo de WireGuard es un acuerdo de claves con autenticación. Se completa en cuanto los pares pueden alcanzarse y tienen claves válidas. El enrutamiento, la política del cortafuegos y el propio destino son preguntas que el saludo nunca plantea.

Así que un túnel puede estar perfectamente establecido mientras cada paquete dentro de él se descarta. Un paquete interno mal enrutado y una respuesta que toma otro camino se ven igual desde el cliente.

Una sola dirección interna es toda la prueba

Elija un destino y quédese con él. La dirección de túnel del propio par es el caso más sencillo, y un equipo detrás del par añade exactamente un salto. Alternar entre ambos sin anotar el cambio produce resultados que nadie puede comparar.

Luego mire la ruta que elige el cliente. Una ruta local más específica puede enviar el paquete a otro sitio antes de que se consulte a WireGuard, lo que ocurre siempre que la LAN doméstica se solapa con el rango remoto.

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

Una dirección que se resuelve a la interfaz física ya ha respondido a la pregunta. El túnel no descarta nada. El paquete nunca entró en él.

Los contadores son pruebas, no un veredicto

wg show informa de los bytes enviados y recibidos por par, y los dos números se mueven de forma independiente. Tome una lectura, haga una petición permitida y luego tome otra lectura dentro del mismo minuto.

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

Los envíos que suben con las recepciones planas son la firma de una petición sin respuesta. No dice si la petición se filtró, si el destino estaba caído o si la respuesta salió por otra ruta. Son tres investigaciones que comparten un síntoma. Sepárelas antes de cambiar cualquier configuración.

Un número fijo de bytes tampoco es un umbral de éxito. Los valores de los contadores siguen al tráfico, y tratar un solo número como prueba de salud produce disparates con mucha seguridad.

El par comprueba él mismo el paquete de vuelta

El par remoto acepta un paquete interno solo cuando el origen cae dentro de su allowedips. Una ruta que exista en el emisor no basta. Una entrada de origen ausente en el receptor descarta el tráfico de vuelta en silencio.

Los cortafuegos del equipo están detrás de esa comprobación. Una regla de reenvío que permite la interfaz del túnel pero no la subred interna acepta el saludo y rechaza el paquete. Desde el lado del cliente eso parece exactamente un par muerto. Un equipo con dos interfaces también puede responder desde el origen equivocado, y entonces el par descarta la respuesta que nunca esperó.

Mantenga el experimento honesto

Probar un perfil de acceso remoto desde la misma red doméstica a la que debe llegar ejercita un camino distinto del previsto. Páse a la red externa y anote su prefijo local, para que las dos ejecuciones se puedan comparar.

Un intercambio pequeño y correcto tampoco descarta todos los problemas de camino. Los paquetes grandes pueden fallar donde pasan los pequeños, y un filtro que coincide por tamaño o protocolo puede comportarse distinto bajo carga.

Mantenga el saludo como la etapa que se sabe que funciona y avance desde ahí. La siguiente prueba útil es dónde se detiene una petición interna, no un juego nuevo de claves y otra ronda de conjeturas.