OpenVPN push-peer-info: etiqueta clientes sin conceder acceso

Las etiquetas de despliegue son el motivo habitual por el que la gente recurre a esta función: cada conexión debería llevar algo como un sitio o un rol, y el servidor debería leerlo sin inventar un segundo formato de credenciales. OpenVPN comunitario ya tiene el mecanismo, y es pequeño. La parte que duele son las expectativas. Establecer una variable corriente en el perfil del cliente no hace nada en el servidor, y un valor que sí llega solo demuestra que el cliente lo envió.

Este es un manual para el camino que funciona, el paso de verificación que muestra qué llegó realmente y la reversión que no deja ningún hook a medio configurar. Nada de esto necesita un certificado nuevo, un plugin nuevo ni una extensión de protocolo.

Establece la variable y habilita el camino

Dos líneas hacen el trabajo en el perfil del cliente, y ambas son necesarias. Sin la primera no hay nada que enviar; sin la segunda el cliente no ofrece información de par en absoluto. El orden no importa, y merece la pena saberlo porque las dos líneas suelen acabar en partes distintas de un perfil generado. Lo importante es que ambas sobrevivan a cualquier reescritura del perfil antes de que el cliente lo lea.

setenv UV_DEPLOY field-support
push-peer-info

El prefijo UV_ no es decoración. Una variable DEPLOY normal se queda local en el proceso del cliente y nunca se reenvía, mientras que la forma con prefijo es el espacio de nombres que el protocolo reserva para los campos definidos por el usuario. Mantén intacto el resto del perfil aprobado y confirma que la compilación del cliente que despliegas admite ambas directivas antes de desplegarla.

Una comprobación práctica corresponde aquí y no al final: asegúrate de que la directiva llega al binario del cliente y no se la traga un envoltorio. Un cliente gráfico que genera su propia línea de comandos, o una interfaz de gestión que recarga un perfil guardado, pueden descartar líneas que no reconocen. Si el servidor no ve nada, este es el primer sitio donde mirar.

Lee el campo desde un hook del servidor

En el lado del servidor, la información de par recibida se valida y se inserta en el entorno del flujo de trabajo de la conexión, y eso es lo que la hace legible desde un hook sin ningún trabajo de protocolo por tu parte. El servidor no necesita analizar el canal de control ni guardar nada por ti; el valor simplemente está presente mientras se establece la conexión. Un script client-connect mínimo que registra la etiqueta junto al nombre autenticado tiene 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

Lee la variable a través del entorno en lugar de analizar el registro, y dale siempre un valor por defecto. ${UV_DEPLOY:-unset} mantiene el script funcionando para los clientes que nunca envían el campo, que es el estado normal durante un despliegue por fases. No vuelques todo el entorno en un registro para encontrar el nombre; contiene mucho más que la etiqueta, incluidos valores que no pretendías conservar.

Ejecuta el script a mano y reportará unset para todo, porque una shell manual no lleva el entorno de la conexión. No es un error del script ni es prueba de que falte el campo. Pruébalo a través de una conexión real, que es el único contexto en el que existe la variable.

Verifica qué llegó realmente

Conecta un cliente con la etiqueta y otro sin ella, y luego lee el archivo. El par es la prueba: una línea debería llevar el valor y la otra el valor por defecto, y ambas deberían nombrar la misma identidad autenticada que esperas.

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

Esas líneas de comentario son la forma de la salida, no una transcripción de tu servidor; lee tu propio archivo. Si el segundo cliente también muestra un valor, la variable está definida en otro lugar del entorno, y estás leyendo una configuración obsoleta en lugar del campo de par.

Revisa también el registro del servidor para la conexión. La información de par puede aparecer ahí, lo que es cómodo para depurar y un motivo para mantener los valores aburridos: sin nombres de personas, sin números de ticket, nada que te importaría que viera un lector del registro.

Trata la etiqueta como una afirmación, no como una identidad

Cualquiera que pueda editar el perfil del cliente puede cambiar la etiqueta, y que el túnel esté autenticado no hace que la etiqueta sea autoritativa. El transporte protege el valor en tránsito; no certifica la afirmación. La autorización sigue perteneciendo a la identidad autenticada y a un registro de inscripción que posee el servidor, y la etiqueta se compara con ese registro cuando importa.

Esa distinción decide dónde puede usarse la etiqueta. Los buenos usos son encaminar una sesión al archivo de registro correcto, elegir un grupo de visualización en un panel o etiquetar una sesión de soporte para que una persona pueda encontrarla más tarde. Los malos usos son admitir un dispositivo en una subred, seleccionar una política de cortafuegos o decidir qué datos de cliente puede leer la sesión.

Valida el valor antes de que llegue a una ruta, una consulta o un comando de shell. Una lista de permitidos de cadenas esperadas basta para una etiqueta de despliegue, y no cuesta nada. Nunca interpoles una cadena proporcionada por el par en una línea de comandos de shell, y limita cualquier observación almacenada a la sesión y no a una dirección de túnel que el siguiente cliente reutilizará.

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

Revertirlo limpiamente

Eliminar la función son dos borrados y una verificación. Elimina las líneas setenv y push-peer-info del perfil del cliente, y luego elimina o desactiva el hook y su destino de registro en el servidor.

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

Vuelve a conectar un cliente después y confirma que la línea de registro deja de aparecer. Un hook que sigue disparándose tras el cambio de perfil suele ser un segundo perfil todavía desplegado en un dispositivo de prueba, y encontrarlo ahora sale más barato que encontrarlo durante una auditoría.

Lo que queda al final es una pieza pequeña y acotada de metadatos de sesión con origen documentado: el cliente la afirma, el servidor la registra y nada del acceso depende de ella. Esa es la versión útil de la función, y no necesita ninguna credencial nueva para llegar ahí.