Perfil de OpenVPN en Git: qué quitar antes de confirmar los cambios

Los perfiles cumplen dos funciones a la vez: registran la configuración de conexión y llevan un paquete de credenciales que funciona. La extensión del archivo no le dice nada sobre cuál de las dos cosas tiene en las manos. Lea el contenido antes de decidir que pertenece a un repositorio.

Los pasos siguientes suponen que se está considerando una plantilla de cliente para el control de versiones. Ejecútelos en orden y deténgase antes de confirmar algo que no pueda revocar.

Lea el archivo que va a preparar

Empiece por los bytes reales, porque un perfil que hace referencia a archivos separados se ve muy distinto de uno que los incrusta. Busque los marcadores de bloque PEM y las etiquetas en línea llamadas ca, cert, key, tls-auth y tls-crypt, y la misma pasada le mostrará ambos casos. Una clave privada cifrada sigue contando como material sensible, y una clave compartida tls-auth o tls-crypt es una credencial aunque no sea la identidad de un usuario. Aplique la misma revisión a todo lo que se prepara junto al perfil, incluidos los archivos comprimidos y los scripts de instalación que hacen referencia a un archivo de credenciales.

Después mire el conjunto preparado y no el árbol de trabajo. git diff --cached muestra qué contendrá realmente la confirmación, y esa es la única versión que importa para esta decisión.

Decida qué puede distribuir el repositorio

Una plantilla puede llevar la configuración compartida y revisada y marcadores de posición con nombre para todo lo que una persona recibe al darse de alta. Lo que no puede llevar es una identidad utilizable, porque un repositorio distribuye a todos los que pueden leerlo, automatización incluida. Un repositorio privado reduce la audiencia sin cambiar la pregunta de si cada lector está autorizado para esa credencial.

Una regla de ignorar impide adiciones futuras y no hace nada con lo que ya está registrado. Esa asimetría merece interiorizarse antes de la primera confirmación y no después de la décima. Los nombres y las direcciones de infraestructura son un juicio aparte: no son secretos de autenticación, pero pueden revelar más de lo que un equipo pretende publicar. Tome esa decisión de forma explícita en lugar de clasificar cada línea en contraseña o público.

Si el material ya está en el historial

Eliminar la línea en una confirmación nueva deja la versión antigua intacta para cualquiera que la descargue. Trate la exposición como real: identifique el tipo de credencial y luego encuentre la autoridad que puede invalidarla. Se revoca el certificado del cliente y se regenera la lista de revocación; una clave compartida del canal de control se sustituye en el servidor y en cada cliente que la usa.

Ambas tienen un radio de impacto muy distinto, y el plan debe indicar cuál está ejecutando antes de empezar. Localice la confirmación que introdujo el material con una búsqueda del tipo git log --all -S 'BEGIN PRIVATE KEY', para que el alcance de la limpieza sea conocido y no supuesto. El clon de un compañero o una bifurcación puede contener ya el objeto antiguo, y por eso la revocación va primero y la limpieza después.

Limpie solo después de contenerlo

Reescribir el historial cambia cada confirmación posterior a la que edita, así que primero necesita el acuerdo del propietario del repositorio y de las personas que trabajan en él. Un envío forzado no es una reparación; es un evento de coordinación con su propio riesgo de reversión. Planifíquelo, haga una copia de seguridad y avise al equipo de cuándo ocurrirá.

Después, verifique el árbol actual y el historial restante en lugar de confiar en el resumen de la herramienta.

Guarde el resultado como dos artefactos: la plantilla que es segura de compartir y el inventario de credenciales emitidas durante el proceso de alta. Ninguno de los dos exige que una identidad utilizable viva en el repositorio.

Esa separación es la solución real, y sobrevive a la siguiente persona que quiera confirmar un perfil.