Quant de temps ha de continuar reintentant OpenConnect una VPN caiguda?

--reconnect-timeout respon una pregunta molt concreta: després que caigui el túnel, quant de temps continua intentant aquest procés client abans de rendir-se i sortir. La pàgina del manual d’OpenConnect registra aquesta opció amb un valor per defecte documentat de 300 segons per als reintents que segueixen una pèrdua d’enllaç o un parell que ha deixat de respondre, i el número és una data límit per a un client en execució, no una prova que la VPN continuï sent abastable. Tampoc no és una política per mantenir viu el procés, i aquí comença la major part de la confusió.

La confusió augmenta quan hi ha un segon mecanisme a sobre. Un supervisor que reinicia el client, un sondejador que fa ping a la passarel·la i la finestra de reintents integrada poden reaccionar tots a una fallada, i l’incident produeix llavors tres cronologies que ningú no pot conciliar.

Què limita realment la finestra de reconnexió

Imagineu que la xarxa d’accés desapareix uns segons. El client veu caure l’enllaç, o deixa de sentir les respostes del parell mort, i comença a restablir la sessió tot conservant l’estat que pot. Els reintents continuen fins que la passarel·la torna a acceptar o fins que s’esgota la finestra, i una finestra esgotada acaba amb una sortida diferent de zero. És aquesta sortida, i no el valor del temps d’espera, on la propietat del cicle de vida passa a qui supervisa el procés.

La finestra no diu res sobre la freqüència amb què s’executa una sonda i no pot ampliar l’autenticació. Si la passarel·la ha revocat la sessió, o el compte ara exigeix un segon factor nou, esperar més no farà que la sessió antiga torni a ser vàlida. Un reintent només té èxit quan el camí torna, la passarel·la encara reconeix la sessió i les credencials que demana continuen sent utilitzables, així que llegiu el número com una data límit i no com un interval de vitalitat.

La finestra tampoc no regeix què fan les aplicacions mentre dura. Segons la plataforma i fins on ha arribat la fallada, el client pot estar reconnectant-se amb les rutes encara instal·lades, o després d’haver-les retirat. Per això una petició emesa enmig d’una interrupció sol penjar fins que expira en lloc de fallar de seguida.

Els reinicis del supervisor i els reintents del client són dues capes

Deixeu que el client en execució gasti la seva pròpia finestra, i que el gestor de serveis reaccioni a la sortida. Un client en primer pla sota systemd amb una política de reinici dona exactament aquesta divisió: reintents durant un període limitat i després una sola decisió de reinici. El resultat és una única cronologia que encara podeu reconstruir després.

Un client en segon pla més un sondejador independent que inicia una altra còpia quan no veu cap interfície és el patró que va malament. Llavors tots dos processos competeixen pel mateix node de dispositiu, les rutes i la configuració del resolutor. Si de debò voleu un dimoni, poseu l’opció a la línia d’ordres amb què el client arrenca realment:

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

Dos detalls d’aquesta línia tenen pes. --background separa el procés, així que el fitxer pid es converteix en l’única nansa fiable que hi ha sobre ell, i el temps d’espera només es gasta mentre aquest mateix procés viu; un supervisor que el mati no deixa cap pressupost per continuar.

Les desconnexions intencionades necessiten el seu propi senyal. Una pausa planificada i una caiguda real semblen idèntiques a un observador ingenu, i totes dues es llegeixen com a «no connectat». Dirigiu la pausa mitjançant l’operació d’aturada del supervisor, o un marcador que l’embolcall entengui, perquè una aturada deliberada no desencadeni un reinici que ningú no ha demanat.

Com evitar que el traspàs competeixi amb el bucle de reintents

La recuperació desatesa depèn de credencials que es renoven sense cap persona present. Un clauer que només s’obre dins d’una sessió d’escriptori interactiva, o un testimoni que sempre necessita un codi teclejat, deixaran el client encallat a l’etapa d’autenticació quan el camí torni. Resoleu aquest flux abans d’allargar la finestra, perquè una finestra més llarga només dona a la mateixa petició bloquejada més temps per fallar.

La verificació del servidor no s’ha de relaxar per reduir les sol·licituds. El pin o l’àncora de confiança que valida la passarel·la és el que fa segura una reconnexió automàtica, i desactivar-lo per evitar una pregunta sobre el certificat canvia una interrupció visible per una d’invisible. Manteniu la identitat verificada i repareu la sol·licitud; un client disposat a connectar-se a qualsevol passarel·la és pitjor que un que s’atura i espera.

La presència de la interfície tampoc no és un senyal de salut. Un dispositiu de túnel pot existir amb una sessió morta al darrere, i un procés de llançament pot existir sense cap túnel. Cap d’aquestes observacions no supera una petició real. La salut ha de venir del que l’usuari necessita, com ara una petició que travessa el túnel fins a un servei intern conegut.

Què cal verificar durant i després d’una interrupció

Executeu quatre esdeveniments com a proves separades: una interrupció més curta que la finestra, una caiguda més llarga que aquesta, una fallada d’autenticació i una aturada intencionada. Cadascuna ha d’acabar en un estat diferent i previsible, i la frontera entre les dues primeres és l’única raó per triar un valor.

Manteniu les comprovacions mirant cap enfora, perquè la taula de processos tota sola demostra molt poc. Mireu que el pid es mantingui estable durant el tall curt i després confirmeu que ha desaparegut i s’ha substituït una vegada després del llarg:

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)"

Durant la interrupció curta, confirmeu que el client ha reintentat de debò en lloc de sortir abans d’hora, i que les rutes i les entrades del resolutor han tornat sense duplicats. Per a la caiguda més llarga, confirmeu una sortida neta i exactament un reinici al darrere. Per a la fallada d’autenticació, confirmeu que el client no gira contra una passarel·la que el continuarà refusant. Afegiu una comprovació que el pid torni a un sol valor en lloc d’acumular-se.

Per a l’aturada deliberada, l’URL de salut ha de continuar sent inabastable i el procés ha de continuar aturat. Després tanqueu el bucle des del costat de l’aplicació: la mateixa petició ha de fallar mentre el túnel no hi és i ha de reeixir després que torni, des de l’adreça d’origen que la vostra política espera. Una icona verda de túnel no és una prova, però una petició completada sí.