CA compartida, puertas separadas: un servicio por archivo de admisión
Un certificado que supera las comprobaciones de la autoridad compartida no es un billete para todos los servicios. La admisión pertenece a un archivo por servicio que el demonio exige.
Un certificado que se valida contra una autoridad compartida ha superado una prueba de confianza, no una prueba de pertenencia. Esas dos decisiones suelen confundirse porque ambas ocurren en el momento de la conexión, y la confusión permanece invisible hasta que se admite en un servicio a alguien que no debería estar en él. La solución no es una segunda autoridad; es una segunda decisión, tomada por servicio y registrada donde el demonio la lee. Mantenga las dos separadas y la mayor parte de la confusión en este terreno desaparece.
Una cadena de confianza no dice nada sobre la pertenencia al servicio
Dos servicios pueden aceptar la misma jerarquía emisora y aun así tener poblaciones distintas. Un portátil pertenece al primero y no debe alcanzar el segundo, mientras que otros clientes de la misma jerarquía sí pertenecen allí. Quitar la autoridad de ese servicio dejaría fuera a todos los que lo usan legítimamente, así que el trabajo es de admisión, no de confianza.
Ayuda imaginar dos cerraduras en una puerta. El certificado abre la cerradura exterior, y una decisión por servicio abre la interior; ninguna sustituye a la otra. Un servicio con solo la cerradura exterior no aplica pertenencia en absoluto, solo autentica. Escriba ambas decisiones antes de tocar nada, porque una política que solo existe en la forma de una conexión que funciona no se puede auditar. Lo que sigue trata de la cerradura interior.
Convierta las sustituciones opcionales en una puerta de admisión
Un directorio de configuración de clientes suele ser una comodidad: los archivos que contiene sustituyen ajustes de los clientes que nombran, y un cliente sin archivo simplemente se ejecuta con los valores predeterminados del servidor. Una directiva convierte esa comodidad en una puerta, de modo que un archivo ausente significa que se rechaza la conexión.
client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive
La edición comunitaria de OpenVPN 2.6 ccd-exclusive en su página de manual documenta exactamente esta condición, y la búsqueda del archivo nombrado depende de la identidad efectiva del cliente. Otras compilaciones y servidores gestionados por productos pueden diferir, así que confirme la versión instalada antes de confiar en la misma semántica en otro lugar.
Trate la ruta anterior como un ejemplo y compruebe la disposición desplegada en lugar de crear un directorio que haya inventado una guía. Deje las comprobaciones de certificados, las comprobaciones de identidad del servidor y la autenticación de cuentas exactamente como estaban, porque el fragmento añade una condición y no quita nada. Prepare el cambio antes de producción, ya que un rechazo planteado en el punto equivocado parece un fallo de certificado y envía la investigación hacia la autoridad. Después confirme que la línea de registro de un cliente rechazado nombra el archivo de configuración ausente y no la cadena.
Un directorio por servicio, no una lista compartida
La pertenencia corresponde al servicio que la aplica, así que cada servicio mantiene su propio directorio y sus propios archivos. Apuntar dos servicios a una lista hace que compartan la pertenencia tanto si alguien lo pretendía como si no, y el cambio resultante es difícil de rastrear hasta una decisión. La autoridad compartida puede seguir compartida; los archivos de admisión no. Mantenerlos separados también significa que un error en un servicio no puede ampliar otro en silencio.
Una entrada DEFAULT es el caso que engaña a la gente. Proporciona ajustes de reserva cuando no se encuentra ningún archivo nombrado, pero no es el archivo nombrado que exige la puerta, así que no puede admitir a un cliente por sí sola. Pruebe un cliente que no tenga ninguna entrada y confirme el rechazo; si ese cliente es admitido, se está aplicando el valor de reserva y ccd-exclusive no está en vigor en esa instancia.
La identidad efectiva decide qué archivo se lee
La búsqueda utiliza la identidad con la que el cliente se autenticó realmente, que normalmente es el nombre común del certificado. Cuando el servidor también verifica un nombre de usuario y una contraseña y asigna ese nombre al nombre común, el archivo debe coincidir con el nombre de usuario autenticado. Una discrepancia deja un directorio lleno de nombres de archivo verosímiles que nunca se seleccionan.
Leer es la otra mitad. El demonio suele abandonar privilegios después del arranque, así que la cuenta reducida necesita acceso de lectura al directorio y a cada entrada. Los clientes no deben poder crear su propia entrada por ninguna ruta en la que se pueda escribir, porque la admisión autoservicio anula por completo el mecanismo. Compruebe los permisos de montaje y de compartición y no solo el modo del archivo, ya que un directorio que parece cerrado para una cuenta puede estar abierto para otra. Después confirme qué cuenta usa realmente el proceso en ejecución, y no qué cuenta menciona el archivo de unidad. Ambas coinciden solo cuando nada más las ha cambiado.
Observe el rechazo, la admisión y la revocación por separado
Pruebe una identidad que pertenece al servicio y confirme que se conecta. Pruebe un certificado válido sin entrada y confirme que se rechaza. Pruebe una identidad admitida en el otro servicio y confirme que aquí no se admite. Anote la instancia del servicio y la identidad efectiva junto a cada resultado, porque un resultado sin ese contexto nadie más puede reproducirlo.
La retirada es una operación distinta de la revocación. Editar un archivo de admisión elimina un derecho de un servicio mientras la identidad sigue siendo válida en todo lo demás, mientras que una clave comprometida requiere la respuesta de revocación de la organización. Decida de antemano qué ocurre con las sesiones ya establecidas, porque ni la edición del directorio ni la lista de revocación las terminan por sí solas.
La admisión también es solo la primera puerta. Unirse a un servicio no dice nada sobre las subredes, las bases de datos o las interfaces de gestión que hay detrás, y esa política de recursos debe escribirse y probarse por separado.