WireGuard PersistentKeepalive: manteña viva a asignación NAT

A caixa da casa abre o túnel e chega ao servidor da nube sen problemas. O servidor da nube pode chegar á aplicación da casa durante un minuto ou dous despois de que a caixa da casa enviase algo por última vez, e despois detense. Non aparece nada no rexistro de WireGuard, non se informa de ningún erro de handshake e reiniciar o túnel arranxa-o brevemente. Ese patrón é unha asignación que caduca, non un túnel roto, e o manual de abaixo confírmao antes de cambiar nada.

Confirme que o patrón é unha caducidade por inactividade

O detalle que o distingue é o momento. Se a conexión inversa funciona xusto despois de que o par da casa envíe tráfico e falla tras un intervalo tranquilo, o camiño está ben e o estado intermedio non. Se nunca funcionou, incluso xusto despois do tráfico, este é un diagnóstico equivocado.

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

Execute os dous primeiros xusto despois de que o par da casa envíe algo, espere cinco minutos e volva executalos. Unha marca de tempo de handshake que se renova segundo o previsto sen un punto final novo dille que o túnel está vivo. O que cambiou é a capacidade dos paquetes non solicitados de chegar desde fóra, que é unha propiedade do camiño e non do túnel.

Despois faga un intento inverso e observe os contadores de transferencia. Se o lado da nube envía bytes e o lado da casa non recibe ningún, o paquete saíu da nube e morreu nun dispositivo con estado polo camiño. Esa é a sinatura que busca. Se ambos os contadores se moven, o túnel entregou o paquete e o sospeitoso é a aplicación.

Pona o keepalive no par detrás do router

Os keepalive persistentes manteñen viva unha asignación NAT e calquera estado da devasa enviando un paquete autenticado pequeno segundo un calendario. O axuste pertence á máquina detrás do router, na súa entrada para o par remoto, porque ese é o lado cuxo paquete saínte crea o estado.

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

Fúndao coa sección de par existente. Engadir un segundo bloque coa mesma chave pública non é unha forma válida de engadir opcións, e wg-quick non as fusionará por vostede. Os 25 segundos documentados son un exemplo elixido para quedar por baixo dos tempos de espera habituais de UDP, non un valor con ningún significado especial.

Pór a mesma directiva no lado da nube non axuda a este problema. Os paquetes dese par xa chegan desde un enderezo público, así que non hai ningunha asignación que preservar na dirección que importa. Engade tráfico e non cambia nada.

Lea os temporizadores en lugar de adiviñar un intervalo

Os keepalive funcionan porque chegan con máis frecuencia da que o estado caduca. Iso converte o tempo de espera no número que realmente necesita, e en Linux pódese ler no dispositivo que fai a tradución:

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

O primeiro valor é o tempo de espera dun fluxo UDP que só se viu nunha dirección, e o segundo aplícase unha vez observadas as respostas. Ambos adoitan ser curtos, e unha asignación que queda calada seguirá o que se aplique ao seu fluxo.

Compare ese número co seu intervalo. Un keepalive de 25 segundos baixo un tempo de espera de 30 segundos funciona; o mesmo keepalive baixo un tempo de espera de 15 segundos non funciona. Ningunha cantidade de reintentos cambia esa aritmética. Algúns routers domésticos e operadores móbiles usan valores moito máis curtos que o predeterminado de Linux, por iso unha configuración que funciona nunha rede falla noutra.

Comprobe o receptor e a devasa por separado

Unha asignación viva é necesaria e non suficiente. A aplicación na caixa da casa ten que escoitar no enderezo correcto, e a devasa do host ten que permitir o paquete despois de descifralo.

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

Se o socket só está vinculado ao enderezo da interface física e non ao enderezo do túnel, os paquetes que chegan polo túnel descártanse antes de consultar a devasa. Ese fallo, desde o lado da nube, parece idéntico a un problema de asignación, e sobrevive a calquera axuste de keepalive.

A comprobación da lista permitida é igual de importante na outra dirección. O par da nube debe permitir o enderezo do túnel da casa como orixe se vai responder, e o par da casa debe permitir o enderezo da nube como destino. Os paquetes keepalive son tráfico autenticado e aplican as mesmas regras, por iso un keepalive que parece funcionar pode convivir cunha aplicación que non funciona.

Despregue o cambio e coñeza os seus límites

Aplique o axuste, reinicie a interface se ese é o seu método de actualización, e despois repita a proba de inactividade en lugar da proba inmediata. Espere máis que o tempo de espera que leu antes, faga unha solicitude inversa e confirme que os contadores se moveron nos dous extremos.

Anote o intervalo e o tempo de espera que mediu xunto a el. Un cambio futuro no firmware do router, ou un traslado a unha conexión móbil, pode alterar o tempo de espera. A nota é o que permite a alguén volver derivar o valor en lugar de copialo. Dous números nunha liña aforran toda unha investigación máis adiante.

Os keepalive persistentes protexen o estado. Non abren un porto, non engaden unha entrada á lista permitida e non fan que apareza un receptor. Cando a conexión inversa non funciona en absoluto, a culpa é unha desas tres, e o inicio rápido de WireGuard describe o axuste de keepalive nos mesmos termos estreitos.