Como deixar o OpenConnect em segundo plano após um login interativo

Conclui o pedido MFA, o túnel sobe e fechar o terminal leva a ligação consigo. É um problema de supervisão, não de autenticação, e o OpenConnect já inclui o interruptor que o resolve. A solução é deixar o cliente ramificar para segundo plano quando o arranque termina, depois de a parte interativa ter acabado de verdade. Segue-se uma sequência de verificações: faça-as por ordem e pare na primeira que não se aplique ao seu gateway.

Confirme o que o gateway exige no login

Antes de escrever um comando, anote o caminho de credenciais imposto pela implementação. Só certificado, palavra-passe mais token e uma ida e volta pelo navegador através de um fornecedor SAML comportam-se de forma diferente, e o modo de segundo plano não pode saltar nenhum. A opção muda o que acontece depois do arranque, nunca durante.

O atalho tentador é automatizar o pedido. Um invólucro que escreve uma resposta fixa quando reconhece um pedido de palavra-passe quebra no momento em que o gateway pede um código de uso único, e deixa uma credencial num ficheiro que outras contas podem ler. Se uma pessoa tem de aprovar a sessão, mantenha a pessoa no processo.

Execute a primeira sessão em primeiro plano e leia a saída

Ligue-se uma vez normalmente e deixe imprimir todo o handshake. Anote o protocolo usado, o caminho do certificado ou do token, o endereço do túnel atribuído pelo servidor e cada aviso antes de a ligação ser aceite. Essa transcrição é a sua linha de base e a única forma barata de distinguir mais tarde um problema do cliente de uma alteração no gateway. Guarde-a fora do buffer do terminal.

Depois repita a mesma invocação com o modo de segundo plano e um ficheiro PID acrescentado, por exemplo openconnect --background --pid-file /run/openconnect.pid vpn.example.net, mantendo o protocolo e as opções de autenticação exigidas pelo gateway na mesma linha. O manual do OpenConnect descreve essa opção como continuação em segundo plano após o arranque, e é exactamente por isso que a fase interativa tem de terminar primeiro.

Torne o processo em execução localizável e parável

Um ficheiro PID só é prova enquanto corresponder a um processo vivo. Coloque-o num diretório propriedade da conta de serviço e compare o número registado com a tabela de processos antes de enviar qualquer sinal. Reinícios e falhas deixam o ficheiro, e um ficheiro obsoleto é a razão habitual de um script de paragem relatar sucesso enquanto o túnel continua ativo. Trate a verificação como parte do procedimento de paragem, não como um passo opcional.

Envie o sinal ao PID verificado e depois confirme que a interface do túnel desapareceu realmente em vez de confiar no estado de saída. Se o cliente precisar de privilégios elevados para configurar a interface, o sinal tem de vir de uma conta autorizada a enviá-lo.

Não empilhe o modo de segundo plano sob um supervisor

O systemd e supervisores semelhantes esperam ser donos do processo que lançaram, e é por isso que um cliente que se ramifica os confunde. O supervisor vê o lançador terminar enquanto a ligação real continua, pelo que a lógica de reinício, os relatórios de estado e os tempos de paragem descrevem algo que já não é verdade. Escreva a unidade no esquema de primeiro plano suportado e deixe o supervisor fazer o trabalho de daemon.

Reserve --background para sessões que uma pessoa inicia e depois abandona. Se o requisito é um túnel que exista antes de alguém iniciar sessão, falta uma identidade não interativa aprovada e um plano para a renovar, e nenhuma opção de linha de comandos fornece qualquer delas. Acrescentar a opção a um script de arranque produz um túnel que falha em silêncio na primeira credencial expirada.

Trate o cookie de sessão como uma credencial

O OpenConnect documenta uma fase de autenticação separada através de --authenticate, e o material resultante pode ser devolvido com --cookie-on-stdin. Esse par existe para trabalho de integração, e o que produz é tão sensível como a palavra-passe que o criou.

Mantenha o valor fora do histórico da shell, dos registos e de qualquer ticket que abra. Um script de entrega também tem de preservar a informação verificada do ponto final que o cliente recebeu com o cookie; se a perder, uma execução posterior pode ligar-se a um anfitrião que nunca autenticou, o que é pior do que uma ligação que simplesmente falha.

Percorra a lista antes de fechar o terminal

Quatro coisas devem ser verdadeiras: o login interativo terminou em primeiro plano, o ficheiro PID aponta para um processo verificado, a questão do supervisor está resolvida num sentido ou no outro e o cookie tem um plano de armazenamento que não é um ficheiro de texto simples. Quando as quatro se verificam, afastar-se do terminal é seguro e o túnel continua.

Se uma falhar, corrija esse ponto antes de tocar nas outras, porque as verificações restantes não o compensam. Guarde também a transcrição de primeiro plano da primeira execução: da próxima vez que o túnel cair sem aviso, essa linha de base separa uma alteração do lado do gateway de uma do lado do cliente.