Como deixar OpenConnect en segundo plano tras un inicio de sesión interactivo

Remata o aviso de MFA, o túnel sobe e pechar o terminal leva consigo a conexión. É un problema de supervisión, non de autenticación, e OpenConnect xa inclúe o interruptor que o resolve. A solución é deixar que o cliente se bifurque en segundo plano cando remate o arranque, unha vez que a parte interactiva acabase de verdade. Segue unha secuencia de comprobacións: fágaas en orde e detéñase na primeira que non se cumpra na súa pasarela.

Confirme que exixe a pasarela ao iniciar sesión

Antes de escribir un comando, anote a ruta de credenciais que impón o despregamento. Só certificado, contrasinal máis token e unha ida e volta polo navegador mediante un provedor SAML compórtanse de forma distinta, e o modo en segundo plano non pode saltar ningún. A opción cambia o que ocorre despois do arranque, nunca o que ocorre durante.

O atallo tentador é automatizar o aviso. Un envoltorio que escribe unha resposta fixa cando recoñece un aviso de contrasinal rompe en canto a pasarela pide un código dun só uso, e deixa unha credencial nun ficheiro que outras contas poden ler. Se unha persoa debe aprobar a sesión, manteña a persoa no circuíto.

Execute a primeira sesión en primeiro plano e lea a saída

Conéctese unha vez con normalidade e deixe que se imprima todo o handshake. Anote o protocolo en uso, a ruta do certificado ou do token, o enderezo do túnel que asigna o servidor e cada aviso antes de aceptar a conexión. Esa transcrición é a súa liña base e a única forma barata de distinguir despois un problema do cliente dun cambio na pasarela. Gárdea fóra do búfer do terminal.

Logo repita a mesma invocación con modo en segundo plano e un ficheiro PID engadido, por exemplo openconnect --background --pid-file /run/openconnect.pid vpn.example.net, mantendo o protocolo e as opcións de autenticación que exixe a súa pasarela na mesma liña. O manual de OpenConnect describe esa opción como continuar en segundo plano tras completarse o arranque, e por iso a fase interactiva debe ter rematado primeiro.

Faga que o proceso en execución sexa localizable e detenible

Un ficheiro PID só é proba mentres coincide cun proceso vivo. Póñao nun directorio propiedade da conta de servizo e compare o número rexistrado coa táboa de procesos antes de enviar calquera sinal. Os reinicios e as caídas deixan o ficheiro atrás, e un ficheiro obsoleto é a razón habitual de que un script de parada informe de éxito mentres o túnel segue activo. Trate a comprobación como parte do procedemento de parada, non como un paso opcional.

Envie o sinal ao PID verificado e logo confirme que a interface do túnel desapareceu realmente en lugar de confiar no estado de saída. Se o cliente necesita privilexios elevados para configurar a interface, o sinal debe vir dunha conta autorizada a envialo.

Non apile o modo en segundo plano baixo un supervisor

systemd e supervisores similares esperan ser donos do proceso que lanzaron, e por iso un cliente que se bifurca confúndeos. O supervisor ve saír un lanzador mentres a conexión real segue viva, así que a lóxica de reinicio, os informes de estado e os tempos de parada describen algo que xa non é certo. Escriba a unidade no esquema de primeiro plano admitido e deixe que o supervisor faga o traballo de demonio.

Reserve --background para sesións que unha persoa inicia e logo abandona. Se o requisito é un túnel que exista antes de que alguén inicie sesión, falta unha identidade non interactiva aprobada e un plan para renovala, e ningún indicador de liña de comandos fornece ningunha das dúas. Engadir o indicador a un script de arranque produce un túnel que falla en silencio coa primeira credencial caducada.

Trate a cookie de sesión como unha credencial

OpenConnect documenta unha fase de autenticación aparte mediante --authenticate, e o material resultante pode devolverse con --cookie-on-stdin. Ese par existe para traballo de integración, e o que produce é tan sensible como o contrasinal que o creou.

Manteña o valor fóra do historial do shell, dos rexistros e de calquera ticket que abra. Un script de entrega tamén debe preservar a información verificada do punto final que o cliente recibiu coa cookie; se a perde, unha execución posterior pode conectarse a un host que nunca autenticou, o que é peor que unha conexión que simplemente falla.

Percorra a lista antes de pechar o terminal

Catro cousas deben ser certas: o inicio de sesión interactivo rematou en primeiro plano, o ficheiro PID apunta a un proceso que verificou, a cuestión do supervisor está resolvida nun sentido ou noutro e a cookie ten un plan de almacenamento que non é un ficheiro de texto plano. Cando as catro se cumpren, afastarse do terminal é seguro e o túnel segue funcionando.

Se unha falla, corrixa ese punto antes de tocar os demais, porque as comprobacións restantes non poden compensalo. Garde tamén a transcrición de primeiro plano da súa primeira execución: a próxima vez que o túnel caia sen aviso, esa liña base separa un cambio do lado da pasarela dun do lado do cliente.