WireGuard PersistentKeepalive: mantenha o mapeamento NAT vivo

A caixa de casa abre o túnel e chega ao servidor na nuvem sem problemas. O servidor na nuvem consegue chegar à aplicação da casa durante um minuto ou dois depois de a caixa de casa ter enviado algo pela última vez, e depois para. Não aparece nada no registo do WireGuard, não é reportado nenhum erro de handshake, e reiniciar o túnel corrige-o brevemente. Esse padrão é um mapeamento que expira, não um túnel avariado, e o guia abaixo confirma-o antes de mudar seja o que for.

Confirme que o padrão é uma expiração por inatividade

O detalhe que o distingue é o momento. Se a ligação inversa funciona logo após o par de casa enviar tráfego e falha depois de um intervalo calmo, o caminho está bem e o estado no meio não. Se nunca funcionou, mesmo logo após tráfego, este é o diagnóstico errado.

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

Execute os dois primeiros logo após o par de casa enviar algo, espere cinco minutos e execute-os novamente. Um registo temporal de handshake que se renova conforme o previsto sem um novo ponto final diz-lhe que o túnel está vivo. O que mudou foi a capacidade de pacotes não solicitados chegarem de fora, que é uma propriedade do caminho e não do túnel.

Depois faça uma tentativa inversa e observe os contadores de transferência. Se o lado da nuvem envia bytes e o lado de casa não recebe nenhum, o pacote deixou a nuvem e morreu num dispositivo com estado pelo caminho. Essa é a assinatura que procura. Se ambos os contadores se movem, o túnel entregou o pacote e o suspeito é a aplicação.

Coloque o keepalive no par atrás do router

Os keepalive persistentes mantêm vivo um mapeamento NAT e qualquer estado da firewall enviando um pequeno pacote autenticado segundo um calendário. A configuração pertence à máquina atrás do router, na sua entrada para o par remoto, porque é o lado cujo pacote de saída cria o estado.

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

Junte-o à secção de par existente. Adicionar um segundo bloco com a mesma chave pública não é uma forma válida de adicionar opções, e o wg-quick não as fundirá por si. Os 25 segundos documentados são um exemplo escolhido para ficar abaixo dos tempos limite UDP comuns, não um valor com qualquer significado especial.

Pôr a mesma diretiva no lado da nuvem não ajuda neste problema. Os pacotes desse par já chegam de um endereço público, por isso não há mapeamento a preservar na direção que importa. Acrescenta tráfego e não muda nada.

Leia os temporizadores em vez de adivinhar um intervalo

Os keepalive funcionam porque chegam com mais frequência do que o estado expira. Isso torna o tempo limite o número de que realmente precisa, e no Linux pode ser lido no dispositivo que faz a tradução:

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 limite de um fluxo UDP que só foi visto numa direção, e o segundo aplica-se depois de observadas respostas. Ambos são normalmente curtos, e um mapeamento que fica silencioso seguirá o que se aplicar ao seu fluxo.

Compare esse número com o seu intervalo. Um keepalive de 25 segundos sob um tempo limite de 30 segundos funciona; o mesmo keepalive sob um tempo limite de 15 segundos não funciona. Nenhuma quantidade de tentativas muda essa aritmética. Alguns routers domésticos e operadores móveis usam valores muito mais curtos do que o padrão do Linux, e é por isso que uma configuração que funciona numa rede falha noutra.

Verifique o ouvinte e a firewall separadamente

Um mapeamento vivo é necessário e não suficiente. A aplicação na caixa de casa tem de escutar no endereço certo, e a firewall do anfitrião tem de permitir o pacote depois de o desencriptar.

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á ligado ao endereço da interface física e não ao endereço do túnel, os pacotes que chegam pelo túnel são descartados antes de a firewall ser consultada. Essa falha, do lado da nuvem, parece idêntica a um problema de mapeamento, e sobrevive a qualquer ajuste do keepalive.

A verificação da lista permitida é igualmente importante na outra direção. O par da nuvem deve permitir o endereço do túnel de casa como origem se vai responder, e o par de casa deve permitir o endereço da nuvem como destino. Os pacotes keepalive são tráfego autenticado e aplicam as mesmas regras, por isso um keepalive que parece funcionar pode coexistir com uma aplicação que não funciona.

Implemente a mudança e conheça os seus limites

Aplique a configuração, reinicie a interface se for esse o seu método de atualização, e depois repita o teste de inatividade em vez do teste imediato. Espere mais do que o tempo limite que leu antes, faça um pedido inverso e confirme que os contadores se moveram nas duas pontas.

Anote o intervalo e o tempo limite medido ao lado. Uma alteração futura ao firmware do router, ou uma mudança para uma ligação móvel, pode alterar o tempo limite. A nota é o que permite a alguém voltar a derivar o valor em vez de o copiar. Dois números numa linha poupam toda uma investigação mais tarde.

Os keepalive persistentes protegem o estado. Não abrem uma porta, não acrescentam uma entrada à lista permitida e não fazem aparecer um ouvinte. Quando a ligação inversa não funciona de todo, a culpa é uma dessas três, e o início rápido do WireGuard descreve a configuração do keepalive nos mesmos termos estreitos.