Identidades VPN individuales para un equipo pequeño, sin directorio

Seis personas comparten un inicio de sesión VPN, una de ellas se va, y la única forma de retirar su acceso es cambiar el secreto que usan todos los demás. Ese es el problema real, y no hace falta Active Directory para resolverlo. Una oficina pequeña puede mantener identidades separadas en el almacén local que admita su puerta de enlace y aun así tratar las salidas como rutina. El trabajo está en elegir el almacén y escribir los pasos de retirada antes de necesitarlos.

Empiece por la credencial que tiene cada persona

Enumere con qué se conecta cada persona antes de elegir un backend. Un portátil, un teléfono, quizá un equipo de escritorio en casa, y cada uno de ellos es una credencial separada o un certificado de dispositivo separado. Si no puede nombrar la credencial que tiene una persona, no podrá retirarla más adelante.

Dos personas que comparten un perfil es el caso que hace más difícil cada paso siguiente. Arregle eso primero, porque ningún directorio resuelve un secreto compartido.

Elija el almacén que la puerta de enlace admite de verdad

Elija el almacén de identidades que la puerta de enlace ya admite, no el que le gustaría ejecutar. Una puerta de enlace con una base de datos local de usuarios puede mantener cuentas individuales con política por usuario. Un despliegue de IKEv2 puede asignar una identidad EAP a un secreto concreto, siempre que el método del cliente y el verificador coincidan. Las configuraciones basadas en certificados pueden emitir un certificado por dispositivo desde una autoridad común, lo que mantiene el ancla de confianza compartida mientras las credenciales siguen separadas.

La ubicación del almacén importa menos que sus operaciones: alta, copia de seguridad, renovación y revocación. Si alguna de ellas no tiene respuesta, la elección no está terminada.

Si la puerta de enlace ofrece cuentas locales y certificados, prefiera la que su equipo pueda operar a las dos de la madrugada sin el proveedor al teléfono. Esa preferencia tiene que ver con el tiempo de recuperación, no con cuál opción es técnicamente más fuerte.

Separe a la persona de los dispositivos

Decida qué representa una credencial: una persona, un dispositivo o ambos. Un portátil y un teléfono de un mismo empleado son dos dispositivos y una persona, y perder el teléfono no debería desactivar necesariamente el portátil. Escriba ese modelo, porque determina qué significa retirar.

Registre el propietario, el dispositivo, la fecha de emisión y la ruta de revocación de cada credencial. Guarde ese registro en un lugar donde la oficina pueda leerlo sin la persona que lo configuró. Una tabla con esas cuatro columnas basta para seis personas y todavía escala hasta sesenta.

Convierta la retirada en una operación habitual

Escriba el procedimiento de salida antes de la primera salida. Desactive la identidad, termine cualquier sesión activa y confirme que el túnel cae de verdad en lugar de esperar un temporizador de reautenticación. Luego compruebe que la credencial anterior falla desde una máquina fuera de la red de la oficina. Toda la secuencia debería llevar minutos y no exigir una reemisión para nadie más.

sudo swanctl --terminate --ike alice-laptop

Mantenga una ruta de recuperación de administrador que no dependa de la cuenta desactivada y concilie las cuentas locales que más adelante pasen a un directorio. El objetivo es simple: retirar a una persona es una tarea rutinaria, no un proyecto que toque el perfil de todos los demás. La autenticación local de Access Server es un ejemplo documentado de un almacén que encaja en esta forma.