VPN mort després de la suspensió: túnel perdut o aplicació obsoleta?

La tapa s’obre, la icona sense fil torna i la VPN encara es mostra com a connectada. Aleshores la primera pàgina interna es penja fins que caduca el temps d’espera, i una pestanya nova fa el mateix. Tres coses diferents poden produir aquesta imatge i necessiten tres arranjaments diferents: un túnel que no va sobreviure a la suspensió, un perfil que ningú no va demanar de reactivar, o una aplicació que encara manté una sessió que va morir fa hores. Comparar-les és més ràpid que reinstal·lar qualsevol cosa.

Tres coses es poden trencar després de despertar

El primer candidat és el túnel mateix. La interfície pot existir encara amb una adreça mentre l’associació amb el parell s’ha perdut, per això un llum indicador no és prova d’un camí que funcioni. Un intercanvi de claus més antic que la suspensió és la pista, i cal una ordre per veure-ho.

El segon és l’activació. Molts clients es reconnecten sols; d’altres no, i un perfil que ningú no demana de tornar es queda allà amb aspecte de configurat. Aquest fracàs és silenciós per disseny, perquè res no ha donat error.

El tercer és l’aplicació. Una pestanya del navegador, una sessió SSH o una connexió a una base de dades poden sobreviure a un canvi de xarxa com a descriptor de fitxer mentre el transport de sota és mort. Aleshores una sessió nova funciona perfectament, cosa que us diu que el túnel estava bé tot el temps.

Compareu les tres abans de canviar res, perquè els arranjaments no es solapen. Reiniciar un client que mai no s’havia demanat de tornar a arrencar malbarata la prova que necessitàveu. Anoteu a quin candidat s’ajusta el símptoma abans de tocar cap configuració. Aquesta sola frase decideix normalment la resta de la investigació.

Primer: ha tornat el túnel?

Mireu la interfície i l’estat del parell en lloc del text d’estat del client. Una interfície amb adreça i sense intercanvi de claus recent és un túnel que només existeix sobre el paper.

ip -brief addr show
wg show
ip route show table all | head -20

Si la interfície falta del tot, el túnel no ha sobreviscut i la pregunta passa a ser qui l’havia de tornar. Si hi és però l’intercanvi de claus és vell, cal restablir l’associació amb el parell i el client pot estar esperant trànsit per activar-la.

Reviseu també les rutes i la configuració de DNS. Un túnel pot tornar sense les seves rutes, cosa que produeix l’estat confús en què la interfície funciona i els noms interns encara es resolen pel servidor equivocat.

Segon: algú va demanar que tornés?

Aquí és on la comparació guanya el seu valor. Un perfil de connector OpenVPN i una connexió nativa de WireGuard es gestionen de manera diferent a NetworkManager, i la referència de paràmetres de connexió diu clarament que connection.autoconnect no activa perfils de VPN; el mecanisme per aixecar una VPN amb una connexió és connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Si reconnectar a mà arregla el problema cada vegada, és el senyal d’una activació absent i no d’un túnel trencat. El registre normalment mostrarà la interfície baixant i res que la torni.

Resistiu l’impuls d’afegir un hook de suspensió de seguida. Un hook que s’executa abans que la xarxa s’hagi recuperat competeix amb el mateix procés al qual intenta ajudar i converteix un problema reproduïble en un d’intermitent.

Tercer: l’aplicació manté estat vell?

Obriu una sessió completament nova cap a la mateixa destinació abans de tocar la VPN. Si la sessió nova funciona i la vella no, el túnel està bé i l’aplicació manté una connexió morta.

Aquesta és la més barata de les tres comprovacions i la que més sovint se salta, perquè la finestra que falla és just a la pantalla. Tanqueu-la, torneu-la a obrir i noteu si el problema sobreviu. Si la sessió nova funciona, atureu del tot la investigació del túnel. Si també falla, l’aplicació és un símptoma i no una causa.

Algunes aplicacions es recuperen soles després d’un temps d’espera, per això pot semblar que el símptoma s’arregla sol al cap de pocs minuts. Aquest comportament apunta a l’aplicació i no al túnel, i val la pena registrar-lo a part. Un company que diu que s’ha arreglat tot sol descriu aquest patró, no una bona sort.

Feu la comparació reproduïble

Mantingueu les variables petites: una xarxa d’accés, una durada de suspensió i la mateixa primera petició cada vegada. Després anoteu dos resultats: si reconnectar a mà ho arregla i si una altra suspensió hi torna a fer fallar.

Aquesta darrera observació és la que separa els tres candidats amb més fiabilitat. Una sessió nova que funciona després d’una de vella fallida no és un problema de túnel, i cap reinstal·lació del client ho canviarà.

El keepalive persistent de WireGuard només entra en aquesta imatge com a keepalive de mapatge NAT. Envia paquets per mantenir un mapatge obert; no impedeix que la màquina se suspengui i no pot continuar enviant mentre el procés està suspès.

Anoteu al tiquet què heu trobat: quina de les tres coses estava trencada, què l’ha arreglada i com ho heu reproduït. La propera persona que obri una tapa un dilluns us ho agrairà, i la resposta no s’haurà de tornar a descobrir des de zero.