WireGuard falla després de la inactivitat: prova primer la direcció

Quatre preguntes precedeixen qualsevol canvi de configuració: el mateix recurs funciona mentre el client és actiu, quant va durar el període d’inactivitat, el dispositiu va dormir o va canviar de xarxa, i la fallada només apareix en el trànsit iniciat pel costat oposat. Les respostes separen una assignació NAT caducada d’una ràdio adormida i d’una aplicació obsoleta. També et diuen si un keepalive és rellevant. Comença per la direcció, perquè costa una ordre i elimina la meitat de les causes possibles.

Quina direcció falla?

Una petició sortint nova del client i el trànsit que hi arriba després d’un període de calma sotmeten l’equip amb estat de maneres diferents. Els paquets sortints reconstrueixen l’assignació mentre surten, mentre que els entrants necessiten que l’assignació antiga hagi sobreviscut. Aquesta asimetria és tota la prova. Si el client pot sortir però no hi arriba res, l’assignació probablement ha caducat, i si no funciona cap de les dues, el túnel o l’accés a la xarxa del client ha desaparegut.

Anota quant va durar el període de calma i si el dispositiu va dormir o va passar a una altra xarxa mentrestant. Aquests dos fets canvien el diagnòstic abans que qualsevol configuració.

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

Executa aquestes tres ordres abans i després del període de calma, perquè cadascuna respon una part diferent de la pregunta. Una marca de temps de handshake que no s’ha mogut diu que les parts han deixat de parlar, mentre que un punt final que ha canviat diu que l’assignació s’ha mogut en lloc de morir. Els comptadors de transferència mostren si ha arribat res, que és la diferència entre una assignació caducada i una aplicació silenciosa. Anota els números en tots dos punts, perquè la comparació és la prova.

Somni, ràdio i estat de l’aplicació

En un telèfon o un portàtil, un dispositiu adormit pot haver perdut del tot l’accés a la xarxa, i un keepalive no pot restablir una ràdio apagada ni completar un portal captiu que no s’ha satisfet. Les plataformes mòbils suspenen la feina en segon pla per política, així que si el trànsit periòdic continua depèn de la plataforma i del que l’aplicació ha negociat amb ella. Una connexió en memòria cau és el tercer cas i el més enganyós, perquè el retorn del túnel no és el mateix que la reconnexió de l’aplicació amb ell.

Torna a obrir l’aplicació després del període d’inactivitat en lloc de confiar en la pestanya que ha quedat oberta. Si una petició nova té èxit on la sessió antiga va fallar, el túnel mai no va ser el problema.

Què fa realment un keepalive

PersistentKeepalive envia periòdicament un paquet buit autenticat a un parell, cosa que n’hi ha prou per mantenir viva una assignació NAT entre parells i perquè el punt final del parell estigui al dia, com descriu l’inici ràpid de WireGuard. No repara una ràdio adormida, una ruta perduda ni una aplicació que no torna a intentar-ho mai. Trieu l’interval amb la configuració compatible del client i no activeu un valor agressiu a tot arreu només perquè una pantalla d’estat es quedi en silenci.

La majoria de períodes d’inactivitat no són fallades. Un túnel que es reconnecta després de cinc minuts de silenci es comporta correctament, i el problema és només el cas en què alguna cosa havia d’arribar del costat oposat.

Espera l’interval que abans fallava

Fes un canvi compatible i deixa passar el mateix període d’inactivitat abans de tornar a provar aquell recurs. Esperar forma part de la prova i no és una formalitat. Un èxit immediat després d’una reconnexió no diu res sobre un símptoma de llarga inactivitat, perquè la reconnexió és exactament l’esdeveniment que reinicia l’estat. Si el problema també apareix durant l’ús actiu, torna a les comprovacions de handshake i de camí de dades en lloc d’afegir més trànsit periòdic.

Mantingues un canvi per prova i anota la durada d’inactivitat utilitzada. Sense això, cada comparació posterior es desvia i ningú no pot dir quin canvi va importar. Anota els quatre fets junts: direcció, durada, estat de son i comportament de l’aplicació.