Como medir o tempo de atividade do cliente OpenVPN com os ganchos up e down

Um painel pede um número de há quanto tempo a conexão está ativa, e OpenVPN não o fornece. O cliente sabe quando o túnel subiu, mas só se algo registar esse momento antes de o estado da sessão se perder. O local suportado é o gancho up, e o valor que vale a pena guardar é um segundo epoch em bruto em vez de uma cadeia formatada. Tudo depois disso é aritmética, mais algumas regras de ordem que decidem se o número se mantém honesto.

Confirme que os ganchos são realmente executados

Prove que o gancho dispara antes de desenhar seja o que for à volta dele. Uma configuração mínima de cliente precisa de script-security 2 e de caminhos explícitos up e down; sem a linha de segurança o OpenVPN recusa executar o script e di-lo claramente. Acrescente up-restart e down-pre ao mesmo tempo, para que os caminhos de reinício e de desmontagem se comportem de forma previsível.

Faça a primeira versão do gancho acrescentar o seu ambiente a um ficheiro e não fazer mais nada. Isso diz-lhe os nomes de variáveis que a sua compilação exporta realmente, como dev e script_type, em vez dos que recorda de outra versão. Execute uma ligação e uma desligação, e depois leia o ficheiro. Se nada aparecer, pare aqui, porque um desenho de carimbo de tempo sobre um gancho que nunca corre parecerá uma falha de monitorização durante semanas.

Verifique com que utilizador o gancho corre. Com user e group definidos, o OpenVPN abdica de privilégios antes de executar scripts, pelo que um diretório onde o root pode escrever pode estar fechado ao gancho. Escolha o caminho do ponto de vista do serviço e não da sua shell.

Registe um único valor epoch e apague-o de propósito

O gancho up precisa de uma linha, date +%s > /run/openvpn-client.started, com o caminho ajustado por instância. Um valor epoch evita mais tarde perguntas de idioma, fuso horário e formato, e é o mesmo número que um agente de monitorização pode comparar com o seu próprio relógio.

Apagar é tão importante como escrever. O gancho down deve esvaziar ou remover o ficheiro, e down-pre faz com que isso aconteça antes de a interface fechar, o que elimina a janela em que o ficheiro descreve um túnel que já desapareceu. up-restart depois renova o carimbo num reinício interno em vez de deixar o valor original no lugar. Sem esse par, um reinício após tempo limite de ping produz um número que continua a subir enquanto o túnel se restabelece.

Escolha um local com a vida útil certa. Um ficheiro em /run desaparece no arranque, o que corresponde à realidade, enquanto um ficheiro em /tmp pode ser limpo de forma imprevisível e um no diretório de configuração sobrevive de uma forma que engana. Defina permissões para que só o utilizador do serviço e o leitor de monitorização o possam ler.

Calcule o tempo de atividade sem confiar nas linhas de registo

Leia o segundo guardado, leia o segundo atual, subtraia. Quando o ficheiro falta ou está vazio, a resposta honesta é que não há túnel ativo, não que o tempo de atividade é zero, porque esses dois estados devem levantar alertas diferentes. Mantenha os segundos em bruto na carga de monitorização e formate dias e horas na camada de apresentação. Um formatador que arredonda dentro do exportador deita fora precisão que alguém vai querer durante um incidente.

Analisar os carimbos de tempo do registo é o atalho tentador, e falha de três maneiras: o formato segue as opções que estiverem definidas, a rotação elimina o histórico e as reconexões aparecem como sessões separadas em vez de um único túnel contínuo. O gancho registra o evento uma vez, no momento em que acontece.

Quando a verificação corre noutro anfitrião, envie o carimbo de tempo em vez da duração para que o leitor aplique o seu próprio relógio. Um pequeno resultado negativo lê-se então como desvio de relógio e não como um gancho avariado.

Cubra reconexões, reinícios e várias instâncias

Dois túneis num só anfitrião precisam de dois ficheiros, com chave pelo nome de instância que o serviço já usa. Um caminho partilhado faz com que a ligação mais recente sobreponha a hora de início de cada perfil, e o sintoma é um número que salta para trás quando um segundo túnel arranca.

O comportamento de reconexão merece um teste próprio, porque é aí que um desenho plausível relata em silêncio a coisa errada. Force um reinício derrubando o par ou enviando um sinal ao processo, e depois compare o estado da interface com o ficheiro. O carimbo de tempo deve avançar no momento em que o túnel regressa.

Do lado do servidor, o ficheiro de estado transporta um valor connected-since por cliente, que responde a outra pergunta: quando é que o servidor viu aquele par pela última vez. Use-o para verificação cruzada e não como substituto, pois desaparece com a sessão que descreve. Nenhuma das medições diz nada sobre a saúde da aplicação por trás do túnel.

Execute as três verificações que apanham erros de ordem

Teste uma ligação normal, uma reconexão forçada e uma paragem limpa, lendo a lista de interfaces e o ficheiro em conjunto depois de cada uma. Um carimbo ainda presente após uma paragem limpa, ou um ficheiro que afirma um túnel que a lista de interfaces não contém, aponta diretamente para a ordem dos ganchos. Execute as verificações como o utilizador do serviço e com os caminhos do serviço, porque uma shell de root pode ver outro ficheiro e dar uma resposta errada com confiança. Depois deixe um sondador lento a ler o ficheiro e confirme que nunca escreve nele.

Um inquérito a cada sessenta segundos cobre os alertas, e nenhum gancho deve contar com a vida desse sondador. Mantenha essas duas responsabilidades separadas e o número continua fiável quando qualquer dos lados é reimplantado.