Socket de gestão do OpenVPN: um canal de controlo, não métricas

Peça um estado à interface de gestão uma vez e ela começa a parecer uma porta de estado. Não é. Assim que um cliente é admitido, pode emitir os comandos de controlo do protocolo, e a conta que executa esse cliente herda tudo o que esses comandos podem fazer ao daemon. Tratá-la como um fluxo só de leitura é o erro que transforma uma integração de monitorização numa consola sem autenticação.

A crença, e o que custa

A crença é que o ouvinte de gestão equivale a um ponto final de métricas: ligue um coletor, leia os contadores, siga em frente. O que acontece na realidade é que o coletor abre uma sessão com capacidades de controlo, e qualquer outra suposição que tenha feito sobre a implementação depende agora de esse coletor se comportar bem.

Nada na interface anuncia um modo só de leitura. Não há nenhum papel de observador para escolher, e um nome de utilizador na configuração não cria um.

O que um cliente admitido tem realmente

O daemon da comunidade aceita apenas um cliente de gestão ativo de cada vez. Esse único lugar significa que uma GUI, um script e um agente de monitorização não podem ligar-se todos; o segundo espera ou falha enquanto o primeiro mantém a sessão. Se o seu desenho assume leitores simultâneos, já está errado.

Onde basta um instantâneo periódico, a saída do ficheiro de estado dá os mesmos números sem uma sessão ativa. Escrever esse ficheiro a intervalos e lê-lo com permissões de ficheiro comuns mantém o coletor totalmente fora do plano de controlo, e é essa a disposição de que a maioria da monitorização precisa realmente.

Um socket próprio, não um aberto

Um socket de domínio Unix mantém o caminho de controlo fora da rede, o que retira do problema o endereço do túnel que muda. Não retira a questão das permissões. O diretório pai tem de ser escrevível pela conta do serviço e acessível pela conta do controlador, e são duas autorizações separadas:

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

O ficheiro de palavra-passe transporta o segredo de gestão na sua primeira linha. Proteja esse ficheiro como qualquer outra credencial e mantenha o seu conteúdo fora dos registos e dos pedidos de suporte. As restrições de utilizador e de grupo são verificações de par no socket Unix, não permissões do sistema de ficheiros, pelo que o processo previsto precisa tanto do acesso ao ficheiro como da identidade correspondente.

Tornar o socket acessível a todo o mundo para resolver um erro de permissões é a única correção a evitar. Converte um canal de controlo local em algo que qualquer processo no anfitrião pode conduzir.

Publicá-lo por TCP não é o mesmo desenho

Mover o ouvinte para uma porta TCP não o torna mais seguro nem mais cómodo. A palavra-passe de gestão é enviada em texto simples, pelo que um ouvinte TCP expõe tanto a credencial como a sessão a quem possa observar o caminho. Chegar a ele a partir de outro anfitrião exige um canal de administração autorizado, ou um pequeno agente local que exponha apenas as observações de que precisa.

Uma palavra-passe sobre um transporte em texto simples é autenticação sem confidencialidade, e essa combinação é pior do que parece porque dá a sensação de estar protegida.

Dependências de arranque que não pediu

Várias opções de gestão alteram o ciclo de vida do daemon. Reter o arranque até um controlador se ligar, ou terminar quando o controlador desaparece, transforma um observador opcional numa dependência rígida. Um agente de monitorização que falhasse levaria então o túnel consigo.

Reveja essas opções antes de ativar qualquer coisa além do próprio socket. A observação opcional deve continuar opcional, e uma política de reinício não deve estar acoplada a um coletor adicionado para gráficos.

Um ficheiro de socket deixado para trás após um processo falhado não é prova de que exista um ouvinte. Identifique que instância possui o caminho antes de o remover, e use o fluxo de recuperação do próprio serviço em vez de apagar ficheiros sob um daemon em execução.

Como se vê a aceitação

Quatro verificações cobrem o desenho: a identidade prevista do controlador liga-se, um processo sem essa identidade é rejeitado, o daemon sobrevive a um controlador que se desliga sem aviso, e o túnel continua a transportar tráfego através de um reinício controlado. Uma ligação de gestão bem-sucedida prova apenas o plano de controlo. Não diz nada sobre se o tráfego de aplicações privadas funciona, por isso teste-o em separado. Escreva os quatro resultados onde o próximo operador os possa encontrar.

A documentação da interface de gestão descreve o modelo de cliente único e a natureza privilegiada do protocolo, e é essa a parte que vale a pena ler antes de apontar um painel para ele.