WireGuard no muestra ningún handshake reciente: qué comprobar primero

Un campo de último handshake vacío suele significar que la interfaz no ha completado ningún handshake desde que se levantó, lo que dice menos sobre la configuración de lo que parece. WireGuard permanece en silencio hasta que un paquete necesita salir por la interfaz, así que un peer inactivo sin nada que enviar informa exactamente de eso. Establezca si realmente se ofreció algo antes de inspeccionar las claves.

La prueba es un paquete permitido hacia un destino que el peer debería transportar. Todo lo demás en esa pantalla de estado describe intención, no actividad.

Una interfaz inactiva no tiene nada que informar

WireGuard hace los handshakes con pereza: el primer paquete que necesita el túnel activa el intercambio y la interfaz calla hasta entonces. Un peer configurado y nunca usado muestra un handshake vacío, cero bytes recibidos y un intervalo creciente desde el último. Ese estado es sano para un cliente inactivo y alarmante solo si esperaba que el tráfico ya hubiera fluido. Revise también los contadores de transferencia, porque separan nada-enviado de intentado-y-fallido.

Si los contadores están a cero en ambos lados, el problema está aguas arriba del túnel. Nada llegó a la interfaz para activar nada.

Active tráfico que el peer tenga permitido transportar

Elija una dirección dentro de los prefijos permitidos del peer, en la máquina local, y confirme que la tabla de enrutamiento la enviaría por la interfaz. Un destino fuera de esos prefijos produce una petición enrutada ordinaria sin ninguna intervención de WireGuard. Use un servicio que responda rápido, como un ping o una conexión TCP corta, para que el intento tenga un principio y un final visibles. Luego vuelva a leer la línea del handshake en lugar de mirar la pantalla y esperar.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

La consulta de ruta importa más que el ping. Si nombra la interfaz física, el paquete nunca entró en el túnel y el handshake vacío es una respuesta de enrutamiento, no criptográfica. Repare la ruta antes de depurar el peer.

Compare el par de claves y el punto final

Una vez que el tráfico se ofrece de verdad, la identidad es la siguiente comprobación. La clave privada local debe corresponder a la clave pública que autoriza el otro lado, la clave pública remota configurada debe identificar el peer previsto y cualquier clave precompartida debe coincidir en ambos extremos. Una diferencia de un solo carácter en una clave base64 produce un peer que parece configurado y nunca completa un intercambio. Compare con el registro de aprovisionamiento en lugar de regenerar claves, porque una clave nueva invalida todos los peers que confiaban en la anterior.

El punto final necesita el mismo escrutinio: nombre de host, dirección, puerto UDP y la familia usada para llegar a él. Una dirección obsoleta o el puerto equivocado producen silencio en lugar de un mensaje.

Vigile la ruta UDP exterior

El handshake viaja como UDP hacia el punto final, así que la ruta exterior tiene que transportarlo. Los comandos de abajo comprueban si existe un receptor, si la pila local emitió el datagrama y qué punto final está configurado. Ejecute la captura mientras activa tráfico, no antes.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

Una captura que muestra el inicio sin respuesta apunta fuera de la máquina, porque el extremo remoto o no escucha, o está filtrado, o está mal direccionado. Una captura que no muestra nada significa que el paquete nunca salió, lo que le devuelve a la ruta y a cualquier marca de socket en juego. Cuando administre ambos extremos, correlacione el intento por marca de tiempo con una captura estrecha en el servidor en lugar de una general. Una prueba de puerto TCP no demuestra nada aquí, porque el protocolo es solo UDP.

Cuando aparezca un handshake, pruebe una aplicación a través del túnel, porque un intercambio completado demuestra identidad y accesibilidad, no un caudal utilizable ni un DNS correcto. Guarde la salida de estado antes y después del cambio, y la diferencia se convierte en su evidencia.