OpenVPN push-peer-info: etiquetar clientes sen conceder acceso

As etiquetas de despregamento son o motivo habitual polo que a xente recorre a esta función: cada conexión debería levar algo como un sitio ou un rol, e o servidor debería lelo sen inventar un segundo formato de credenciais. OpenVPN comunitario xa ten o mecanismo, e é pequeno. A parte que doe son as expectativas. Establecer unha variable corrente no perfil do cliente non fai nada no servidor, e un valor que si chega só demostra que o cliente o enviou.

Este é un manual para o camiño que funciona, o paso de verificación que mostra que chegou realmente e a reversión que non deixa ningún hook a medio configurar. Nada aquí necesita un certificado novo, un plugin novo nin unha extensión de protocolo.

Establece a variable e activa o camiño

Dúas liñas fan o traballo no perfil do cliente, e ambas son necesarias. Sen a primeira non hai nada que enviar; sen a segunda o cliente non ofrece información de par en absoluto. A orde non importa, e paga a pena sabelo porque as dúas liñas adoitan acabar en partes distintas dun perfil xerado. O importante é que ambas sobrevivan a calquera reescritura do perfil antes de que o cliente o lea.

setenv UV_DEPLOY field-support
push-peer-info

O prefixo UV_ non é decoración. Unha variable DEPLOY normal queda local no proceso do cliente e nunca se reenvía, mentres que a forma con prefixo é o espazo de nomes que o protocolo reserva para os campos definidos polo usuario. Mantén intacto o resto do perfil aprobado e confirma que a compilación do cliente que despregas admite ambas directivas antes de despregala.

Unha comprobación práctica corresponde aquí e non ao final: asegúrate de que a directiva chega ao binario do cliente e non a traga un envoltorio. Un cliente gráfico que xera a súa propia liña de comandos, ou unha interface de xestión que recarga un perfil gardado, poden descartar liñas que non recoñecen. Se o servidor non ve nada, este é o primeiro sitio onde mirar.

Le o campo desde un hook do servidor

No lado do servidor, a información de par recibida valídase e insírese na contorna do fluxo de traballo da conexión, e iso é o que a fai lexible desde un hook sen ningún traballo de protocolo pola túa parte. O servidor non precisa analizar a canle de control nin gardar nada por ti; o valor simplemente está presente mentres se establece a conexión. Un script client-connect mínimo que rexistra a etiqueta xunto ao nome autenticado ten este aspecto.

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

Le a variable a través da contorna en lugar de analizar o rexistro, e dálle sempre un valor por defecto. ${UV_DEPLOY:-unset} mantén o script funcionando para os clientes que nunca envían o campo, que é o estado normal durante un despregamento por fases. Non botes toda a contorna nun rexistro para atopar o nome; contén moito máis que a etiqueta, incluídos valores que non pretendías conservar.

Executa o script á man e informará unset para todo, porque unha shell manual non leva a contorna da conexión. Non é un erro do script nin é proba de que falta o campo. Proba a través dunha conexión real, que é o único contexto no que existe a variable.

Verifica que chegou realmente

Conecta un cliente coa etiqueta e outro sen ela, e despois le o ficheiro. O par é a proba: unha liña debería levar o valor e a outra o valor por defecto, e ambas deberían nomear a mesma identidade autenticada que esperas.

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

Esas liñas de comentario son a forma da saída, non unha transcrición do teu servidor; le o teu propio ficheiro. Se o segundo cliente tamén mostra un valor, a variable está definida noutro lugar da contorna, e estás lendo unha configuración obsoleta en lugar do campo de par.

Revisa tamén o rexistro do servidor para a conexión. A información de par pode aparecer alí, o que é cómodo para depurar e un motivo para manter os valores aburridos: sen nomes de persoas, sen números de tícket, nada que che importaría que vise un lector do rexistro.

Trata a etiqueta como unha afirmación, non como unha identidade

Calquera que poida editar o perfil do cliente pode cambiar a etiqueta, e que o túnel estea autenticado non fai que a etiqueta sexa autoritativa. O transporte protexe o valor en tránsito; non certifica a afirmación. A autorización segue pertencendo á identidade autenticada e a un rexistro de inscrición que posúe o servidor, coa etiqueta comparada con ese rexistro cando importa.

Esa distinción decide onde se pode usar a etiqueta. Bos usos son encamiñar unha sesión ao ficheiro de rexistro correcto, escoller un grupo de visualización nun panel ou etiquetar unha sesión de soporte para que unha persoa a atope máis tarde. Malos usos son admitir un dispositivo nunha subrede, seleccionar unha política de devasas ou decidir que datos de cliente pode ler a sesión.

Valida o valor antes de que chegue a unha ruta, unha consulta ou un comando de shell. Unha lista de permitidos de cadeas esperadas abonda para unha etiqueta de despregamento, e non custa nada. Nunca interpoles unha cadea proporcionada polo par nunha liña de comandos de shell, e limita calquera observación almacenada á sesión e non a un enderezo de túnel que o seguinte cliente reutilizará.

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

Reverteo limpiamente

Eliminar a función son dous borrados e unha verificación. Elimina as liñas setenv e push-peer-info do perfil do cliente, e despois elimina ou desactiva o hook e o seu destino de rexistro no servidor.

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

Volve conectar un cliente despois e confirma que a liña de rexistro deixa de aparecer. Un hook que segue disparando tras o cambio de perfil adoita ser un segundo perfil aínda despregado nun dispositivo de proba, e atopalo agora sae máis barato que atopalo durante unha auditoría.

O que queda ao final é unha peza pequena e acoutada de metadatos de sesión con orixe documentada: o cliente afírmoa, o servidor rexístraa e nada do acceso depende dela. Esa é a versión útil da función, e non precisa ningunha credencial nova para chegar aí.