WireGuard PersistentKeepalive: mantenga viva la asignación NAT

La caja de casa abre el túnel y llega al servidor en la nube sin problemas. El servidor en la nube puede llegar a la aplicación de casa durante un minuto o dos después de que la caja de casa enviara algo por última vez, y luego deja de hacerlo. No aparece nada en el registro de WireGuard, no se informa de ningún error de handshake y reiniciar el túnel lo arregla brevemente. Ese patrón es una asignación que caduca, no un túnel roto, y el manual de abajo lo confirma antes de cambiar nada.

Confirme que el patrón es una caducidad por inactividad

El detalle que lo distingue es el momento. Si la conexión inversa funciona justo después de que el par de casa envíe tráfico y falla tras un intervalo tranquilo, el camino está bien y el estado intermedio no. Si nunca funcionó, incluso justo después del tráfico, este es un diagnóstico equivocado.

sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transfer

Ejecute los dos primeros justo después de que el par de casa envíe algo, espere cinco minutos y vuelva a ejecutarlos. Una marca de tiempo de handshake que se renueva según lo previsto sin un punto final nuevo le dice que el túnel está vivo. Lo que cambió es la capacidad de los paquetes no solicitados de llegar desde fuera, que es una propiedad del camino y no del túnel.

Después haga un intento inverso y observe los contadores de transferencia. Si el lado de la nube envía bytes y el lado de casa no recibe ninguno, el paquete salió de la nube y murió en un dispositivo con estado por el camino. Esa es la firma que busca. Si ambos contadores se mueven, el túnel entregó el paquete y el sospechoso es la aplicación.

Ponga el keepalive en el par detrás del router

Los keepalive persistentes mantienen viva una asignación NAT y cualquier estado del cortafuegos enviando un paquete autenticado pequeño según un calendario. El ajuste pertenece a la máquina detrás del router, en su entrada para el par remoto, porque ese es el lado cuyo paquete saliente crea el estado.

[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25

Fusiónelo con la sección de par existente. Añadir un segundo bloque con la misma clave pública no es una forma válida de añadir opciones, y wg-quick no las fusionará por usted. Los 25 segundos documentados son un ejemplo elegido para quedar por debajo de los tiempos de espera habituales de UDP, no un valor con ningún significado especial.

Poner la misma directiva en el lado de la nube no ayuda a este problema. Los paquetes de ese par ya llegan desde una dirección pública, así que no hay ninguna asignación que preservar en la dirección que importa. Añade tráfico y no cambia nada.

Lea los temporizadores en lugar de adivinar un intervalo

Los keepalive funcionan porque llegan con más frecuencia de la que el estado caduca. Eso convierte el tiempo de espera en el número que realmente necesita, y en Linux se puede leer en el dispositivo que hace la traducción:

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820

El primer valor es el tiempo de espera de un flujo UDP que solo se ha visto en una dirección, y el segundo se aplica una vez observadas las respuestas. Ambos suelen ser cortos, y una asignación que se queda callada seguirá el que se aplique a su flujo.

Compare ese número con su intervalo. Un keepalive de 25 segundos bajo un tiempo de espera de 30 segundos funciona; el mismo keepalive bajo un tiempo de espera de 15 segundos no funciona. Ninguna cantidad de reintentos cambia esa aritmética. Algunos routers domésticos y operadores móviles usan valores mucho más cortos que el predeterminado de Linux, por eso una configuración que funciona en una red falla en otra.

Compruebe el receptor y el cortafuegos por separado

Una asignación viva es necesaria y no suficiente. La aplicación en la caja de casa tiene que escuchar en la dirección correcta, y el cortafuegos del host tiene que permitir el paquete después de descifrarlo.

sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/health

Si el socket solo está vinculado a la dirección de la interfaz física y no a la dirección del túnel, los paquetes que llegan por el túnel se descartan antes de consultar el cortafuegos. Ese fallo, desde el lado de la nube, parece idéntico a un problema de asignación, y sobrevive a cualquier ajuste de keepalive.

La comprobación de la lista permitida es igual de importante en la otra dirección. El par de la nube debe permitir la dirección del túnel de casa como origen si va a responder, y el par de casa debe permitir la dirección de la nube como destino. Los paquetes keepalive son tráfico autenticado y aplican las mismas reglas, por eso un keepalive que parece funcionar puede convivir con una aplicación que no funciona.

Despliegue el cambio y conozca sus límites

Aplique el ajuste, reinicie la interfaz si ese es su método de actualización, y luego repita la prueba de inactividad en lugar de la prueba inmediata. Espere más que el tiempo de espera que leyó antes, haga una solicitud inversa y confirme que los contadores se movieron en ambos extremos.

Anote el intervalo y el tiempo de espera que midió junto a él. Un cambio futuro en el firmware del router, o un traslado a una conexión móvil, puede alterar el tiempo de espera. La nota es lo que permite a alguien volver a derivar el valor en lugar de copiarlo. Dos números en una línea ahorran toda una investigación más adelante.

Los keepalive persistentes protegen el estado. No abren un puerto, no añaden una entrada a la lista permitida y no hacen que aparezca un receptor. Cuando la conexión inversa no funciona en absoluto, la culpa es una de esas tres, y el inicio rápido de WireGuard describe el ajuste de keepalive en los mismos términos estrechos.