WireGuard PersistentKeepalive: manteniu viva l’assignació NAT

La caixa de casa obre el túnel i arriba al servidor del núvol sense problemes. El servidor del núvol pot arribar a l’aplicació de casa durant un minut o dos després que la caixa de casa hagi enviat alguna cosa per última vegada, i llavors s’atura. No apareix res al registre de WireGuard, no es notifica cap error d’encaixada, i reiniciar el túnel ho arregla durant una estona. Aquest patró és una assignació que caduca, no un túnel trencat, i el manual de sota ho confirma abans de canviar res.

Confirmeu que el patró és una caducitat per inactivitat

El detall que ho distingeix és el moment. Si la connexió inversa funciona just després que el parell de casa enviï trànsit i falla després d’un interval tranquil, el camí està bé i l’estat del mig no. Si mai no ha funcionat, fins i tot just després del trànsit, aquest diagnòstic és erroni.

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

Executeu les dues primeres ordres just després que el parell de casa enviï alguna cosa, espereu cinc minuts i torneu-les a executar. Una marca de temps d’encaixada que es renova segons la programació sense cap punt final nou us diu que el túnel és viu. El que ha canviat és la capacitat dels paquets no sol·licitats d’arribar de fora, que és una propietat del camí i no del túnel.

Després feu un intent invers i mireu els comptadors de transferència. Si la banda del núvol envia bytes i la de casa no en rep cap, el paquet ha sortit del núvol i ha mort en un dispositiu amb estat pel camí. Aquesta és la signatura que busqueu. Si tots dos comptadors es mouen, el túnel ha lliurat el paquet i el sospitós és l’aplicació.

Poseu el keepalive al parell darrere del router

Els keepalive persistents mantenen viva una assignació NAT i qualsevol estat del tallafoc enviant un paquet autenticat petit segons una programació. El paràmetre pertany a la màquina darrere del router, a la seva entrada per al parell remot, perquè és el costat el paquet sortint del qual crea l’estat.

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

Fusiona’l amb la secció de parell existent. Afegir un segon bloc amb la mateixa clau pública no és una manera vàlida d’afegir opcions, i wg-quick no les fusionarà per vosaltres. Els 25 segons documentats són un exemple triat per quedar per sota dels temps d’espera habituals d’UDP, no un valor amb cap significat especial.

Posar la mateixa directiva a la banda del núvol no ajuda aquest problema. Els paquets d’aquest parell ja arriben d’una adreça pública, així que no hi ha cap assignació a preservar en la direcció que importa. Afegeix trànsit i no canvia res.

Llegiu els temporitzadors en lloc d’endevinar un interval

Els keepalive funcionen perquè arriben més sovint del que caduca l’estat. Això fa que el temps d’espera sigui el número que realment necessiteu, i a Linux es pot llegir al dispositiu que fa la traducció:

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 és el temps d’espera d’un flux UDP que només s’ha vist en una direcció, i el segon s’aplica quan s’han observat respostes. Tots dos solen ser curts, i una assignació que calla seguirà el que s’apliqui al vostre flux.

Compareu aquest número amb el vostre interval. Un keepalive de 25 segons amb un temps d’espera de 30 segons funciona; el mateix keepalive amb un temps d’espera de 15 segons no funciona. Cap quantitat de reintents no canvia aquesta aritmètica. Alguns routers de consum i operadors mòbils fan servir valors molt més curts que el valor per defecte de Linux, i per això una configuració que funciona en una xarxa falla en una altra.

Comproveu l’escoltador i el tallafoc per separat

Una assignació viva és necessària i no suficient. L’aplicació de la caixa de casa ha d’escoltar a l’adreça correcta, i el tallafoc de l’amfitrió ha de permetre el paquet després de desxifrar-lo.

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

Si el sòcol només està lligat a l’adreça de la interfície física i no a l’adreça del túnel, els paquets que arriben pel túnel es descarten abans de consultar el tallafoc. Aquesta fallada, des de la banda del núvol, sembla idèntica a un problema d’assignació, i sobreviu a cada ajust de keepalive.

La comprovació de la llista permesa és igual d’important en l’altra direcció. El parell del núvol ha de permetre l’adreça del túnel de casa com a origen si ha de respondre, i el parell de casa ha de permetre l’adreça del núvol com a destinació. Els paquets keepalive són trànsit autenticat i apliquen les mateixes regles, i per això un keepalive que sembla funcionar pot conviure amb una aplicació que no funciona.

Desplegueu el canvi i conegueu-ne els límits

Apliqueu el paràmetre, reinicieu la interfície si aquest és el vostre mètode d’actualització, i després repetiu la prova d’inactivitat en lloc de la prova immediata. Espereu més que el temps d’espera que heu llegit abans, feu una sol·licitud inversa i confirmeu que els comptadors s’han mogut als dos extrems.

Anoteu l’interval i el temps d’espera que heu mesurat al costat. Un canvi futur al firmware del router, o un trasllat a una connexió mòbil, pot alterar el temps d’espera. La nota és el que permet a algú tornar a derivar el valor en lloc de copiar-lo. Dos números en una línia estalvien tota una investigació més endavant.

Els keepalive persistents protegeixen l’estat. No obren cap port, no afegeixen cap entrada a la llista permesa i no fan aparèixer cap escoltador. Quan la connexió inversa no funciona de cap manera, la culpa és una d’aquestes tres, i l’inici ràpid de WireGuard descriu el paràmetre keepalive en els mateixos termes estrictes.