VPN bloqueada tras reiniciar o router: tres cousas que cambiaron

O router remata de arrincar, o portátil volve unirse ao mesmo SSID e a VPN queda en conectada sen que nada se mova. O perfil gardado está intacto. O que caducou por debaixo foi a ruta, e o cliente segue conservando o estado que construíu para a anterior.

Tres condicións deciden a solución. Compóboas por orde, porque as posteriores son esforzo perdido se a primeira xa explica o bloqueo.

Primeira condición: o enderezo local cambiou

Un reinicio pode asignar á máquina un enderezo distinto. Entón unha VPN configurada cun punto final local fixo segue usando unha conexión que xa non existe. O mesmo ocorre cun cliente que vinculou o seu socket ao enderezo antigo. A interface do túnel pode seguir activa mentres cada paquete que xera vai a un lugar inútil.

Compara o enderezo que usa o cliente co que ten agora a interface. Unha ruta predeterminada que apunta a unha pasarela que tamén cambiou é a mesma clase de problema con outro nome.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Segunda condición: o mapeo traducido desapareceu

Os routers domésticos traducen os fluxos saíntes, e eses mapeos viven na memoria. Un reinicio borra todos e cada un deles. Iso é inofensivo para unha conexión nova e fatal para un túnel que cre que o seu fluxo existente segue sendo válido. Entón o outro extremo non ve nada, así que o cliente nunca recibe un erro sobre o que poida actuar.

Aquí é onde un túnel sen keepalives se atasca en silencio en lugar de fallar ruidosamente. As limitacións documentadas de WireGuard describen a mesma forma de fallo. Un estado de punto final incorrecto produce paquetes descartados en lugar dun diagnóstico.

Un keepalive persistente de 25 segundos é a mitigación habitual, porque refresca o mapeo antes de que poida caducar un tempo de espera por inactividade. Non repara un mapeo que xa desapareceu. Combina o keepalive coa lóxica de reconexión en lugar de tratalo como unha solución.

Terceira condición: o enderezo público cambiou

Se cambiou o enderezo externo do propio router, calquera cousa no outro lado que filtre por enderezo de orixe ve agora un interlocutor distinto. O túnel pode levantarse e o servidor pode seguir descartando o tráfico, o que parece un cliente avariado e en realidade é unha política do outro extremo.

Anota o enderezo externo antes e despois do reinicio. Cando os dous difiren, a pregunta pasa do cliente a quen mantén a lista de permitidos, e restablecer as credenciais no portátil non pode axudar.

Recupera na orde correcta

Completa primeiro calquera inicio de sesión obrigatorio no portal cativo, despois deixa que o cliente se reconecte mediante o seu procedemento admitido en lugar de matar o proceso. Observa se se recuperan tanto a identidade como o tráfico de datos, porque son dúas etapas distintas da mesma conexión.

Unha páxina en caché non demostra nada, nin tampouco unha aplicación de chat que se reconectou soa. Proba o punto final que de verdade che importa cunha solicitude nova. Mantén a política de tráfico directo durante a interrupción, porque un intento de reconexión non é un bloqueo.

Cando isto se repite tras cada reinicio, o rexistro importa máis que o reintento. Anota o enderezo local, a pasarela, o enderezo externo e o estado do cliente antes e despois, e compara as dúas columnas. Iso converte unha queixa vaga nun erro de ciclo de vida que alguén pode corrixir, e evita que os certificados se substitúan por terceira vez por un tempo de espera do mapeo.