WireGuard falla tras a inactividade: proba primeiro a dirección

Catro preguntas preceden calquera cambio de configuración: funciona o mesmo recurso mentres o cliente está activo, canto durou o período de inactividade, durmiu o dispositivo ou cambiou de rede, e a falla aparece só no tráfico que inicia o lado oposto. As respostas separan unha asignación NAT caducada dunha radio durmida e dunha aplicación obsoleta. Tamén din se un keepalive é sequera relevante. Comeza pola dirección, porque custa un comando e elimina a metade das causas posibles.

Que dirección falla?

Unha nova petición saínte do cliente e o tráfico que chega cara a el tras un período de calma someten de xeito distinto o equipo con estado. Os paquetes saíntes reconstruyen unha asignación ao saír, mentres que os entrantes necesitan que a asignación antiga sobrevivise. Esa asimetría é toda a proba. Se o cliente pode saír pero non entra nada, a asignación probablemente caducou, e se non funciona ningunha das dúas, o túnel ou o acceso de rede do cliente desapareceu.

Anota canto durou o período de calma e se o dispositivo durmiu ou pasou a outra rede mentres tanto. Eses dous feitos cambian o diagnóstico antes ca calquera configuración.

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

Executa eses tres comandos antes e despois do período de calma, porque cada un responde a unha parte distinta da pregunta. Unha marca de tempo de handshake que non se moveu di que as partes deixaron de falar, mentres que un extremo que cambiou di que a asignación se moveu en lugar de morrer. Os contadores de transferencia amosan se chegou algo, que é a diferenza entre unha asignación caducada e unha aplicación silenciosa. Anota os números nos dous puntos, porque a comparación é a proba.

Sono, radio e estado da aplicación

Nun teléfono ou nun portátil, un dispositivo durmido pode ter perdido por completo o acceso á rede, e un keepalive non pode restaurar unha radio apagada nin completar un portal cativo que non se satisfixo. As plataformas móbiles suspenden o traballo en segundo plano por política, así que se o tráfico periódico continúa depende da plataforma e do que a aplicación negociou con ela. Unha conexión en caché é o terceiro caso e o máis enganoso, porque o regreso do túnel non é o mesmo ca a reconexión da aplicación a el.

Volve abrir a aplicación tras o período de inactividade en lugar de confiar na pestana que quedou aberta. Se unha petición nova ten éxito onde fallou a sesión antiga, o túnel nunca foi o problema.

Que fai realmente un keepalive

PersistentKeepalive envía periodicamente un paquete baleiro autenticado a un par, o que abonda para manter viva unha asignación NAT entre pares e para que o extremo do par siga actualizado, como describe o inicio rápido de WireGuard. Non repara unha radio durmida, unha ruta perdida nin unha aplicación que nunca reintenta. Escolle o intervalo coa configuración compatible do cliente e non actives un valor agresivo en todas partes só porque unha pantalla de estado queda en silencio.

A maioría dos períodos de inactividade non son fallos. Un túnel que se reconecta tras cinco minutos de silencio compórtase correctamente, e o problema é só o caso en que algo debía chegar do lado oposto.

Espera o intervalo que antes fallaba

Fai un cambio compatible e deixa pasar o mesmo período de inactividade antes de volver probar ese recurso. Esperar forma parte da proba e non é unha formalidade. O éxito inmediato tras unha reconexión non di nada sobre un síntoma de inactividade longa, porque a reconexión é xusto o acontecemento que reinicia o estado. Se o problema tamén aparece durante o uso activo, volve ás comprobacións de handshake e de ruta de datos en lugar de engadir máis tráfico periódico.

Mantén un cambio por proba e anota a duración de inactividade usada. Sen iso, cada comparación posterior desvía e ninguén pode dicir que cambio importou. Rexistra os catro feitos xuntos: dirección, duración, estado de sono e comportamento da aplicación.