VPN morta tras a suspensión: túnel perdido ou aplicación obsoleta?

A tapa ábrese, a icona sen fíos volve e a VPN segue mostrándose como conectada. A primeira páxina interna entón bloquéase ata esgotar o tempo de espera, e unha lapela nova fai o mesmo. Tres cousas distintas poden producir esa imaxe e necesitan tres arranxos distintos: un túnel que non sobreviviu á suspensión, un perfil que ninguén pediu reactivar, ou unha aplicación que aínda mantén unha sesión que morreu hai horas. Comparalas é máis rápido que reinstalar calquera cousa.

Tres cousas poden estar rotas tras espertar

O primeiro candidato é o propio túnel. A interface pode seguir existindo cun enderezo mentres a asociación co par desapareceu, por iso unha luz indicadora non é proba dunha ruta que funcione. Un intercambio de claves máis antigo que a suspensión é a pista, e abonda un comando para velo.

O segundo é a activación. Moitos clientes reconéctanse sos; outros non, e un perfil que ninguén pide que volva queda aí con aspecto de configurado. Ese fallo é silencioso por deseño, porque nada deu erro.

O terceiro é a aplicación. Unha lapela do navegador, unha sesión SSH ou unha conexión a unha base de datos poden sobrevivir a un cambio de rede como descritor de ficheiro mentres o transporte de debaixo está morto. Entón unha sesión nova funciona perfectamente, o que lle di que o túnel estaba ben todo o tempo.

Compare as tres antes de cambiar nada, porque os arranxos non se solapan. Reiniciar un cliente ao que nunca se lle pediu volver arrincar malgasta a proba que necesitaba. Anote a que candidato encaixa o síntoma antes de tocar unha configuración. Esa soa frase adoita decidir o resto da investigación.

Primeiro: volveu o túnel?

Mire a interface e o estado do par en lugar do texto de estado do cliente. Unha interface con enderezo e sen intercambio de claves recente é un túnel que só existe sobre o papel.

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

Se a interface falta por completo, o túnel non sobreviviu e a pregunta pasa a ser quen debía devolvelo. Se está presente pero o intercambio de claves é vello, hai que restablecer a asociación co par, e o cliente pode estar esperando tráfico para activala.

Revise tamén as rutas e a configuración de DNS. Un túnel pode volver sen as súas rutas, o que produce o estado confuso no que a interface funciona e os nomes internos aínda se resolven polo servidor equivocado.

Segundo: pediu algo que volvese?

Aquí é onde a comparación se gaña o seu sitio. Un perfil de complemento OpenVPN e unha conexión nativa de WireGuard trátanse de forma distinta en NetworkManager, e a referencia de axustes de conexión di claramente que connection.autoconnect non activa perfís de VPN; o mecanismo para levantar unha VPN cunha conexión é connection.secondaries.

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

Se reconectar a man arranxa o problema todas as veces, é a sinatura dunha activación ausente e non dun túnel roto. O rexistro normalmente amosará a interface caendo e nada que a devolva.

Resista o impulso de engadir un hook de suspensión de inmediato. Un hook que se dispara antes de que a rede se recuperase compite co mesmo proceso ao que intenta axudar, e converte un problema reproducible en intermitente.

Terceiro: mantén a aplicación estado vello?

Abra unha sesión completamente nova cara ao mesmo destino antes de tocar a VPN. Se a sesión nova funciona e a vella non, o túnel está ben e a aplicación mantén unha conexión morta.

Esta é a máis barata das tres comprobacións e a que máis se omite, porque a xanela que falla está xusto na pantalla. Péchea, volva abrila e anote se o problema sobrevive. Se a sesión nova funciona, deteña por completo a investigación do túnel. Se tamén falla, a aplicación é un síntoma e non unha causa.

Algunhas aplicacións recupéranse soas tras un tempo de espera, por iso pode parecer que o síntoma se arranxa só ao cabo duns minutos. Ese comportamento apunta á aplicación e non ao túnel, e merece rexistrarse á parte. Un compañeiro que di que se arranxou só describe este patrón, non unha sorte.

Faga a comparación reproducible

Manteña as variables pequenas: unha rede de acceso, unha duración de suspensión e a mesma primeira petición cada vez. Despois rexistre dous resultados: se reconectar a man o arranxa e se outra suspensión volve traer o fallo.

Esa última observación é a que separa os tres candidatos con máis fiabilidade. Unha sesión nova que funciona despois dunha vella fallida non é un problema de túnel, e ningunha reinstalación do cliente o cambiará.

O keepalive persistente de WireGuard só entra nesta imaxe como keepalive de asignación NAT. Envía paquetes para manter unha asignación aberta; non impide que a máquina se suspenda e non pode seguir enviando mentres o proceso está suspendido.

Anote no tícket que atopou: cal das tres cousas estaba rota, que a arranxou e como o reproduciu. A próxima persoa que abra unha tapa un luns agradecerallo, e a resposta non terá que redescubrirse desde cero.