Canto tempo debe OpenConnect seguir reintentando unha VPN caída?

--reconnect-timeout responde a unha pregunta moi concreta: cando cae o túnel, canto tempo segue intentándoo este proceso cliente antes de renderse e saír. A páxina do manual de OpenConnect rexistra esa opción cun valor predeterminado documentado de 300 segundos para os reintentos que seguen a perda da ligazón ou a un par que deixou de responder, e o número é unha data límite para un cliente en execución, non unha proba de que a VPN siga sendo accesible. Tampouco é unha política para manter vivo o proceso, e aí comeza a maior parte da confusión.

A confusión aumenta cando por riba hai un segundo mecanismo. Un supervisor que reinicia o cliente, un sondador que fai ping á pasarela e a xanela de reintentos integrada poden reaccionar todos a un mesmo fallo, e o incidente produce entón tres cronoloxías que ninguén pode conciliar.

Que limita realmente a xanela de reconexión

Imaxina que a rede de acceso desaparece durante uns segundos. O cliente ve caer a ligazón, ou deixa de oír as respostas do par morto, e comeza a restablecer a sesión conservando o estado que pode. Os reintentos continúan ata que a pasarela volve aceptar ou ata que se esgota a xanela, e unha xanela esgotada remata nunha saída distinta de cero. É esa saída, e non o valor do tempo de espera, onde a propiedade do ciclo de vida pasa a quen supervise o proceso.

A xanela non di nada sobre a frecuencia con que se executa unha sonda, e non pode ampliar a autenticación. Se a pasarela revogou a sesión, ou a conta esixe agora un segundo factor novo, esperar máis non fará que a sesión antiga volva ser válida. Un reintento só ten éxito cando o camiño volve, a pasarela segue recoñecendo a sesión e as credenciais que pide seguen sendo utilizables, así que lea o número como unha data límite e non como un intervalo de vitalidade.

A xanela tampouco goberna o que fan as aplicacións mentres dura. Segundo a plataforma e ata onde chegou o fallo, o cliente pode estar reconectándose coas rutas aínda instaladas, ou despois de que se retirasen. Por iso unha petición emitida no medio dunha interrupción adoita quedar colgada ata esgotar o tempo de espera en lugar de fallar rápido.

Os reinicios do supervisor e os reintentos do cliente son dúas capas

Deixe que o cliente en execución gaste a súa propia xanela, e que o xestor de servizos reaccione á saída. Un cliente en primeiro plano baixo systemd cunha política de reinicio dá exactamente esa división: reintentos durante un período acoutado e despois unha soa decisión de reinicio. O resultado é unha única cronoloxía que aínda pode reconstruír despois.

Un cliente en segundo plano máis un sondador independente que inicia outra copia cando non ve unha interface é o patrón que sae mal. Ambos os procesos compiten entón polo mesmo nodo de dispositivo, as rutas e a configuración do resolutor. Se de verdade quere un demonio, poña a opción na liña de ordes coa que o cliente arranca en realidade:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Dous detalles desa liña pesan. --background separa o proceso, así que o ficheiro pid convértese na única asa fiable que hai sobre el, e o tempo de espera só se consume mentres ese mesmo proceso vive; un supervisor que o mata non deixa orzamento para continuar.

As desconexións intencionadas necesitan o seu propio sinal. Unha pausa planificada e unha caída real resultan idénticas a un observador inxenuo, e ambas se len como «non conectado». Dirixa a pausa mediante a operación de parada do supervisor, ou unha marca que o envoltorio entenda, para que unha detención deliberada non dispare un reinicio que ninguén pediu.

Evitar que a transferencia compita co bucle de reintentos

A recuperación desatendida depende de credenciais que se renovan sen unha persoa presente. Un chaveiro que só se desbloquea dentro dunha sesión interactiva de escritorio, ou un token que sempre esixe un código tecleado, deixarán o cliente atascado na fase de autenticación cando o camiño volva. Resolva ese fluxo antes de alongar a xanela, porque unha xanela máis longa só dá á mesma solicitude bloqueada máis tempo para fallar.

A verificación do servidor non se debe relaxar para reducir solicitudes. Precisamente o pin ou a áncora de confianza que valida a pasarela é o que fai segura unha reconexión automática, e desactivalo para evitar unha pregunta sobre o certificado cambia unha interrupción visible por outra invisible. Conserve a identidade verificada e repare a solicitude no seu lugar; un cliente disposto a conectarse a calquera pasarela é peor que un que se detén e espera.

A presenza da interface tampouco é un sinal de saúde. Un dispositivo de túnel pode existir cunha sesión morta detrás, e un proceso lanzador pode existir sen túnel ningún. Ningunha desas observacións resiste unha petición real. A saúde ten que vir do que o usuario necesita, como unha petición que atravesa o túnel ata un servizo interno coñecido.

Que verificar durante e despois dunha interrupción

Execute catro sucesos como probas separadas: unha interrupción máis curta que a xanela, unha caída máis longa ca esta, un fallo de autenticación e unha parada intencionada. Cada un debe rematar nun estado distinto e previsible, e a fronteira entre os dous primeiros é toda a razón para elixir un valor.

Manteña as comprobacións mirando cara a fóra, porque a táboa de procesos por si soa demostra moi pouco. Observe que o pid se manteña estable durante o corte curto e despois confirme que desapareceu e se substituíu unha vez tras o longo:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Durante a interrupción curta, confirme que o cliente reintentou de verdade en lugar de saír antes de tempo, e que as rutas e as entradas do resolutor volveron sen duplicados. Para a caída longa, confirme unha saída limpa e exactamente un reinicio despois. Para o fallo de autenticación, confirme que o cliente non xira contra unha pasarela que seguirá rexeitándoo. Engada unha comprobación de que o pid volve a un só valor en lugar de acumularse.

Para a parada deliberada, o URL de saúde debe seguir sendo inalcanzable e o proceso debe seguir caído. Despois peche o bucle desde o lado da aplicación: a mesma petición debe fallar mentres o túnel non está e debe ter éxito tras o seu regreso, desde o enderezo de orixe que a súa política espera. Unha icona verde de túnel non é unha proba, pero unha petición completada si o é.