OpenVPN push-peer-info: rotular clientes sem conceder acesso

As tags de implantação são o motivo habitual pelo qual as pessoas recorrem a esse recurso: cada conexão deve carregar algo como um site ou um papel, e o servidor deve ler isso sem inventar um segundo formato de credencial. O OpenVPN da comunidade já tem o mecanismo, e ele é pequeno. A parte que dói são as expectativas. Definir uma variável comum no perfil do cliente não faz nada no servidor, e um valor que até chega prova apenas que o cliente o enviou.

Este é um guia para o caminho que funciona, o passo de verificação que mostra o que realmente chegou e a reversão que não deixa nenhum hook pela metade. Nada aqui exige um novo certificado, um novo plugin ou uma extensão de protocolo.

Defina a variável e habilite o caminho

Duas linhas fazem o trabalho no perfil do cliente, e ambas são necessárias. Sem a primeira, não há nada a enviar; sem a segunda, o cliente não oferece informação de par nenhuma. A ordem não importa, e vale a pena saber disso porque as duas linhas costumam terminar em partes diferentes de um perfil gerado. O importante é que ambas sobrevivam a qualquer reescrita do perfil antes de o cliente lê-lo.

setenv UV_DEPLOY field-support
push-peer-info

O prefixo UV_ não é decoração. Uma variável DEPLOY comum permanece local ao processo do cliente e nunca é encaminhada, enquanto a forma com prefixo é o espaço de nomes que o protocolo reserva para campos definidos pelo usuário. Mantenha o restante do perfil aprovado intacto e confirme, antes de implantar, que a compilação do cliente que você está usando suporta as duas diretivas.

Uma verificação prática pertence aqui, e não ao final: garanta que a diretiva chegue ao binário do cliente e não seja engolida por um wrapper. Um cliente gráfico que gera a própria linha de comando, ou uma interface de gestão que recarrega um perfil salvo, pode descartar linhas que não reconhece. Se o servidor não vê nada, este é o primeiro lugar a olhar.

Leia o campo a partir de um hook do servidor

No lado do servidor, a informação de par recebida é validada e inserida no ambiente do fluxo de conexão, e é isso que a torna legível a partir de um hook sem nenhum trabalho de protocolo da sua parte. O servidor não precisa analisar o canal de controle nem armazenar nada para você; o valor simplesmente está presente enquanto a conexão é estabelecida. Um script client-connect mínimo que registra a etiqueta ao lado do nome autenticado tem esta aparência.

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

Leia a variável pelo ambiente em vez de analisar o log, e dê a ela sempre um valor padrão. ${UV_DEPLOY:-unset} mantém o script funcionando para clientes que nunca enviam o campo, que é o estado normal durante uma implantação gradual. Não despeje todo o ambiente num log para encontrar o nome; ele contém muito mais que a etiqueta, incluindo valores que você não pretendia guardar.

Execute o script à mão e ele relatará unset para tudo, porque um shell manual não carrega o ambiente da conexão. Isso não é um bug do script e não é prova de que o campo esteja faltando. Teste-o por meio de uma conexão real, o único contexto em que a variável existe.

Verifique o que realmente chegou

Conecte um cliente com a etiqueta e um sem ela, e então leia o arquivo. O par é o teste: uma linha deve carregar o valor e a outra o padrão, e ambas devem nomear a mesma identidade autenticada que você espera.

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

Essas linhas de comentário são a forma da saída, não uma transcrição do seu servidor; leia o seu próprio arquivo. Se o segundo cliente também mostrar um valor, a variável está definida em outro lugar do ambiente, e você está lendo uma configuração antiga em vez do campo de par.

Verifique também o log do servidor para a conexão. A informação de par pode aparecer ali, o que é conveniente para depuração e um motivo para manter os valores entediantes: sem nomes de pessoas, sem números de chamado, nada que você não gostaria que um leitor do log visse.

Trate a etiqueta como afirmação, não como identidade

Qualquer pessoa que possa editar o perfil do cliente pode alterar a etiqueta, e o fato de o túnel ser autenticado não torna a etiqueta autoritativa. O transporte protege o valor em trânsito; ele não certifica a afirmação. A autorização continua pertencendo à identidade autenticada e a um registro de inscrição que o servidor possui, com a etiqueta comparada a esse registro quando isso importa.

Essa distinção decide onde a etiqueta pode ser usada. Bons usos são encaminhar uma sessão ao arquivo de log correto, escolher um grupo de exibição num painel ou marcar uma sessão de suporte para que uma pessoa a encontre depois. Maus usos são admitir um dispositivo numa sub-rede, selecionar uma política de firewall ou decidir quais dados de cliente a sessão pode ler.

Valide o valor antes que ele chegue a um caminho, uma consulta ou um comando de shell. Uma lista de permissões de strings esperadas basta para uma etiqueta de implantação, e não custa nada. Nunca interpole uma string fornecida pelo par numa linha de comando shell, e limite qualquer observação armazenada à sessão e não a um endereço de túnel que o próximo cliente reutilizará.

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

Reverta com limpeza

Remover o recurso são duas exclusões e uma verificação. Remova as linhas setenv e push-peer-info do perfil do cliente e, em seguida, remova ou desative o hook e o destino de log dele no servidor.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

Reconecte um cliente depois e confirme que a linha de log deixa de aparecer. Um hook que continua disparando após a mudança de perfil geralmente é um segundo perfil ainda implantado num dispositivo de teste, e encontrá-lo agora custa menos do que encontrá-lo durante uma auditoria.

O que resta no final é um pedaço pequeno e delimitado de metadados de sessão com origem documentada: o cliente a afirma, o servidor a registra, e nada do acesso depende dela. Essa é a versão útil do recurso, e ela não precisa de nenhuma credencial nova para chegar lá.