VPN encallat després de reiniciar el router: tres coses que han canviat

El router acaba d'arrencar, l'ordinador portàtil es torna a unir al mateix SSID i la VPN es queda a connectat sense que es mogui res. El perfil desat és intacte. El que havia caducat a sota era el camí, i el client encara conserva l'estat que va construir per al camí antic.

Tres condicions decideixen la solució. Comprova-les per ordre, perquè les posteriors són esforç perdut si la primera ja explica l'encallament.

Primera condició: l'adreça local ha canviat

Un reinici pot assignar a la màquina una adreça diferent. Llavors una VPN configurada amb un punt final local fix continua utilitzant un enllaç que ja no existeix. El mateix passa amb un client que va lligar el seu sòcol a l'adreça antiga. La interfície del túnel pot continuar activa mentre cada paquet que genera va a un lloc inútil.

Compara l'adreça que utilitza el client amb l'adreça que té ara la interfície. Una ruta per defecte que apunta a una passarel·la que també ha canviat és la mateixa classe de problema amb un altre nom.

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

Segona condició: el mapatge traduït ha desaparegut

Els routers domèstics tradueixen els fluxos sortints, i aquests mapatges viuen a la memòria. Un reinici esborra tots i cada un d'ells. Això és inofensiu per a una connexió nova i fatal per a un túnel que creu que el seu flux existent encara és vàlid. Llavors l'altre extrem no veu res, i el client no rep mai cap error sobre el qual pugui actuar.

Aquí és on un túnel sense keepalives s'encalla en silenci en lloc de fallar sorollosament. Les limitacions documentades de WireGuard descriuen la mateixa forma de fallada. Un estat de punt final incorrecte produeix paquets descartats en lloc d'un diagnòstic.

Un keepalive persistent de 25 segons és la mitigació habitual, perquè refresca el mapatge abans que pugui caducar un temps d'espera per inactivitat. No repara un mapatge que ja ha desaparegut. Combina el keepalive amb lògica de reconnexió en lloc de tractar-lo com una solució.

Tercera condició: l'adreça pública ha canviat

Si l'adreça externa del propi router ha canviat, qualsevol cosa a l'altre costat que filtri per adreça d'origen ara veu un altre interlocutor. El túnel pot aixecar-se i el servidor pot continuar descartant el trànsit, cosa que sembla un client espatllat i en realitat és una política de l'altre extrem.

Anota l'adreça externa abans i després del reinici. Quan les dues difereixen, la pregunta passa del client a qui manté la llista d'autoritzats, i restablir les credencials a l'ordinador portàtil no pot ajudar.

Recupera-ho en l'ordre correcte

Primer completa qualsevol inici de sessió obligatori al portal captiu, després deixa que el client es reconnecti pel seu procediment suportat en lloc de matar el procés. Observa si es recuperen tant la identitat com el trànsit de dades, perquè són dues etapes diferents de la mateixa connexió.

Una pàgina en memòria cau no demostra res, ni tampoc una aplicació de missatgeria que s'ha reconectat sola. Prova el punt final que realment t'importa amb una sol·licitud nova. Mantén la política de trànsit directe durant la interrupció, perquè un intent de reconnexió no és un bloqueig.

Quan això es repeteix després de cada reinici, el registre importa més que el reintent. Anota l'adreça local, la passarel·la, l'adreça externa i l'estat del client abans i després, i compara les dues columnes. Això converteix una queixa vaga en un error de cicle de vida que algú pot corregir, i evita que els certificats es tornin a substituir per tercera vegada per un temps d'espera del mapatge.