El handshake de WireGuard funciona pero no hay internet: sigue el paquete

El túnel está activo, wg show informa de un handshake reciente, puedes hacer ping a la dirección del túnel del servidor y nada más allá responde. El instinto es regenerar las claves o volver a compartir la configuración. Eso cambia justo la parte del camino que ya está demostrado que funciona.

Un handshake completado dice que los dos pares coinciden en las claves, que UDP llega al extremo y que el enrutamiento criptográfico acepta el paquete. No dice nada sobre si el paquete puede salir del servidor después.

Así que sigue un solo paquete en lugar de adivinar. Hay cuatro lugares donde puede morir, y cada uno deja un rastro distinto.

Qué demuestra realmente el handshake

WireGuard es un protocolo UDP que establece una sesión con un handshake Noise y luego cifra los paquetes de un par. Cuando wg show muestra un handshake de hace unos segundos y un contador de transferencia creciente, el extremo, las claves y la clave pública del par son todos correctos.

Lo que no demuestra es que tu cliente envíe tráfico hacia internet a la interfaz, que el servidor esté dispuesto a reenviarlo o que una respuesta pueda encontrar el camino de vuelta. Esas son decisiones de enrutamiento del núcleo y del cortafuegos, y se toman fuera del túnel.

Por eso hacer ping a la dirección del túnel del servidor es una prueba tan engañosa. Ese paquete está dirigido al propio servidor, así que termina localmente. Nunca necesita reenvío, nunca necesita traducción y nunca necesita una ruta de vuelta desde internet.

AllowedIPs es una decisión de enrutamiento

En el cliente, AllowedIPs hace dos trabajos. Es la tabla de enrutamiento de clave criptográfica que decide qué direcciones de destino se envían al túnel de este par, y es la lista de direcciones de origen que el par aceptará de ti. Si la configuración del cliente solo enumera 10.8.0.0/24, los destinos públicos nunca entran en la interfaz y tu ruta predeterminada normal los lleva fuera del túnel. Entonces el túnel funciona perfectamente y no hace nada de lo que querías.

Mira lo que el cliente instaló realmente en lugar de lo que dice el archivo de configuración:

wg show wg0 allowed-ips
ip route get 1.1.1.1

El segundo comando es el decisivo. Si la respuesta nombra tu interfaz física y la puerta de enlace normal, el paquete no se está tunelizando y ningún cambio del lado del servidor lo arreglará. Añade 0.0.0.0/0 para IPv4 y ::/0 para IPv6 por separado; una regla que lo abarca todo para una familia deja la otra en su camino original, y eso es una causa habitual de un túnel IPv4 que funciona y una consulta IPv6 atascada.

Dónde muere el paquete en la puerta de enlace

Si la ruta es correcta y el paquete sigue sin ir a ninguna parte, llega al servidor y se detiene allí. Cuatro comprobaciones cubren la mayoría de las puertas de enlace.

Reenvío. sysctl net.ipv4.ip_forward devolviendo 0 es la respuesta clásica, y muchas distribuciones siguen en 0 por defecto. Debe ser 1, y fijarse de forma persistente en un archivo sysctl en lugar de con un comando que desaparece al reiniciar. El reenvío de IPv6 es un interruptor aparte.

La política de filtrado. Una cadena FORWARD con política de descarte por defecto descartará el tráfico del túnel mientras permite el tráfico hacia el propio host, lo que encaja exactamente con el síntoma. Lee el conjunto de reglas vivo, no un archivo guardado: nft list ruleset o iptables -S.

Traducción o enrutamiento. Los clientes con direcciones de túnel privadas necesitan o bien NAT de origen en la interfaz de salida del servidor, o bien un prefijo enrutado que la red superior sepa devolver. Elegir entre ambos sigue el plan de direcciones. Añadir MASQUERADE a una red que ya enruta tu prefijo de vuelta es inofensivo pero inútil, y omitirlo donde no existe ninguna ruta deja las respuestas dirigidas a un rango privado no enrutable.

El camino de vuelta. En diseños enrutados, el router superior necesita una ruta que apunte a tu servidor. La red del proveedor también puede bloquearlo: varias nubes activan una comprobación de origen y destino en la instancia, que descarta en silencio los paquetes cuyo origen no es la dirección propia de la instancia hasta que se desactiva esa comprobación.

El DNS falla de forma distinta al enrutamiento

Un paquete a una dirección conocida y una consulta de nombre son fallos separados, y los mensajes de error engañan en direcciones opuestas. Si ping 1.1.1.1 funciona y un navegador no carga nada, la ruta está bien y la resolución de nombres no. Si el ping en sí falla, el DNS es irrelevante y vuelves a la sección anterior.

wg-quick puede establecer un resolutor a partir de la línea DNS = de la configuración, y systemd-resolved tiene su propio comportamiento por enlace. Una VPN que sobrescribe el resolutor con una dirección solo alcanzable dentro del túnel hará fallar cada consulta en el momento en que caiga el túnel, lo que parece que el túnel rompe internet.

Un orden que produce pruebas

Ejecuta primero la comprobación del lado del cliente, porque es un solo comando y elimina la mitad de las posibilidades. Luego confirma si el servidor está pensado para ser una salida a internet; una puerta de enlace hecha para acceso privado no está rota cuando fallan los destinos públicos.

En el servidor, observa la interfaz mientras envías un ping desde el cliente: tcpdump -ni wg0 icmp debería mostrar la petición, y tcpdump -ni eth0 icmp debería mostrar que sale, traducida o no. Si aparece en el primero y nunca en el segundo, la parada es local al servidor. Si sale y no vuelve ninguna respuesta, el problema está más arriba, y esa es otra conversación.

Por último, haz que la corrección sobreviva a un reinicio. El reenvío pertenece a un archivo sysctl, las reglas del cortafuegos pertenecen al servicio que las carga, y las rutas del cliente pertenecen a la configuración que levanta la interfaz en lugar de a un shell que olvidarás. Vuelve a conectarte, repite las mismas dos pruebas y confirma que los contadores se mueven.