Handshake activo, dirección perdida: tres estados de WireGuard
Un handshake reciente demuestra que el par respondió, no que la interfaz conserve su dirección ni que el siguiente paquete tome el enlace ascendente previsto.
WireGuard puede tener un handshake reciente y ninguna dirección a la vez, y ese estado es coherente, no contradictorio. El handshake es un evento del par, la dirección pertenece a la interfaz y la ruta decide por qué enlace ascendente sale un paquete. Tres capas, tres dueños, y cada una puede fallar mientras las otras dos parecen sanas.
Leerlos como un solo estado es lo que convierte un diagnóstico de dos minutos en una tarde entera de reiniciar servicios.
Un handshake es un evento del par, no un evento de direccionamiento
El handshake de WireGuard demuestra que el par configurado respondió con una clave válida y que las claves de sesión están al día. No dice nada sobre la dirección local de la interfaz, ni sobre si alguna ruta apunta allí. La dirección la asigna un asistente o un gestor de red, mientras que la configuración del protocolo solo nombra pares y claves. Confundir ambas cosas es como un handshake sano se lee como un túnel que funciona.
Por eso wg show puede informar de un handshake de hace segundos en una interfaz que no puede aceptar ni un paquete de una aplicación.
Un gestor que recrea la interfaz puede perder la dirección sin tocar la configuración del par, y el siguiente handshake tiene éxito de inmediato porque las claves nunca cambiaron. La línea del registro sobre un handshake correcto es exacta e irrelevante para el fallo.
| Observation | Which layer it belongs to | Wrong conclusion it invites |
|---|---|---|
| Handshake a few seconds old | Peer and keys | The tunnel is usable for application traffic |
Address present on wg0 | Interface configuration | Traffic actually egresses through it |
Route points at wg0 | Forwarding table | The outer packet uses the intended uplink |
La dirección de la interfaz tiene su propio dueño
Una dirección en el dispositivo de túnel puede venir de la línea Address de un asistente, de un cliente DHCP que se ejecuta en la interfaz o de un demonio de gestión que la crea al conectar. Sea cual sea, ese componente posee la dirección y la restaurará o no según su propia lógica. Leer la dirección sin nombrar a su dueño te deja sin explicación de por qué desapareció.
Dos dueños en una interfaz es el fallo clásico. Arrancar un asistente y un gestor de red de escritorio sobre el mismo dispositivo produce una carrera en la que uno elimina lo que el otro acaba de configurar, y el extremo sigue respondiendo todo el tiempo.
Elige un solo dueño y deja que la otra herramienta observe en lugar de gestionar. Esa decisión merece anotarse, porque el síntoma aparece semanas después y parece una pérdida aleatoria de dirección.
La ruta elige un enlace ascendente, la interfaz no
Una ruta interna que apunta a wg0 decide que el tráfico entra en el túnel. Una decisión aparte envía los paquetes externos cifrados hacia el par, y en un equipo con varios enlaces ascendentes esa decisión viene de la tabla de reenvío y de las reglas de política. Un roaming Wi-Fi puede cambiar el camino externo sin tocar la dirección interna.
Así, un túnel que funciona y un par inalcanzable son estados compatibles, y también lo son un par correcto y una ruta interna rota. Las tres observaciones deben tomarse juntas, en el mismo momento, o la comparación no significa nada.
Compare los tres estados en una sola pasada
Tres comandos de solo lectura responden a las tres preguntas en el orden que aísla el fallo más rápido. Ejecútelos sin cambiar nada entre ellos.
ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer
El primero muestra si la interfaz tiene alguna dirección, y el segundo muestra qué dispositivo usaría ahora un destino concreto. El tercero informa de la hora del último handshake y de los contadores de bytes, y es el único de los tres que describe al par y no al equipo local.
Lea los contadores además de la marca de tiempo. Un handshake que se refresca continuamente mientras la transferencia sigue plana significa que el par responde pero no pasa nada útil, lo que apunta al enrutamiento o a una ACL y no a las claves. Una marca de tiempo que deja de avanzar con una dirección presente apunta más arriba. Ambas lecturas salen de la misma línea de salida, y ninguna se ve si solo comprueba que exista un handshake.
Corrija el estado concreto que está mal y luego vuelva a probar la aplicación, no el túnel. Un handshake reciente es evidencia del par, y la evidencia sobre el par no es evidencia de que la próxima petición de su navegador encuentre una dirección, una ruta y un enlace ascendente que funcione. El manual de wg-quick dice explícitamente cuáles de esas cosas monta el asistente y cuáles pertenecen al protocolo.