Gana la primera sesión: restringir los inicios de sesión de OpenVPN antes del desalojo
Rechazar un inicio de sesión posterior no es lo mismo que sustituir el anterior. La decisión debe tomarse antes del desalojo del mismo nombre, y la comprobación de la ranura tiene que ser atómica.
Una política que permite una sesión por cuenta parece resuelta hasta que llega el segundo inicio de sesión. Son posibles dos desenlaces: el recién llegado sustituye a la sesión existente, o la sesión existente conserva la ranura y el recién llegado es rechazado. Solo el segundo es una política de gana la primera sesión. La opción de cliente a la que recurre la mayoría activa la concurrencia y, por tanto, no la produce.
Dos contratos se esconden tras un solo ajuste
Con la concurrencia desactivada, una segunda conexión que presente el mismo nombre de certificado puede desplazar la sesión que ya está en marcha. Activar la concurrencia permite varias sesiones a la vez, que es lo contrario de un límite. Ninguno de los dos estados es una política de rechazo, así que la decisión debe tomarse en otro sitio por completo.
Escriba el contrato antes de implementar nada: quién es rechazado, qué evidencia identifica a la sesión existente y qué ocurre cuando una sesión muere sin una desconexión limpia. Una política que nadie ha formulado así no puede probarse después.
El desalojo llega antes que su gancho de conexión
En la ruta de código del servidor 2.6, la preparación temprana de un cliente nuevo elimina las instancias existentes con el mismo nombre cuando la concurrencia está desactivada. Esa eliminación ocurre antes de que se ejecute la cadena de manejadores de conexión. Por eso un script que detecta el duplicado y devuelve un fallo rechaza al recién llegado después de que la sesión existente ya haya sido expulsada, justo el resultado que la política pretendía evitar. El orden de las devoluciones de llamada en la implementación upstream es la única respuesta fiable para su compilación.
| Stage | Who can still refuse | Effect on the incumbent |
|---|---|---|
| Certificate check | Server trust configuration | None |
| Authentication decision | The authentication controller | None, because establishment has not run |
| Connect handler | A profile script | Already evicted in the same-name case |
| Post-establishment | Status tooling, monitoring | Both sessions already exist or one is gone |
Sondear el archivo de estado tampoco es una puerta. Dos intentos que llegan a la vez pueden ver ambos una ranura vacía antes de que ninguno la confirme, y ambos continúan.
Lleve la decisión a la autenticación
La interfaz de administración puede asumir la decisión de autenticación tras verificar el certificado. En esa disposición el controlador no es un monitor: recibe cada instancia de cliente que se conecta y responde si esa instancia puede continuar. Como la respuesta llega antes del establecimiento, un rechazo deja intacta la sesión existente. El mismo canal informa de las desconexiones, y así el controlador sabe que una ranura se liberó legítimamente.
Toda instancia nueva debe pasar esa puerta, incluidas las reconexiones y cualquier ruta que se reautentique sin aviso. Una puerta a la que algunas instancias nunca llegan no protege nada, y la omisión permanece invisible hasta que alguien prueba el atajo.
Los tokens pueden pasar de largo por la puerta
Una vez emitido un token, el servidor puede validarlo internamente y omitir la autenticación externa para esa conexión. La llamada de administración nunca ocurre, así que una comprobación de ranura implementada solo allí nunca ve la instancia nueva. Ese comportamiento es una comodidad para los usuarios y un agujero para una política de concurrencia. Haga que las conexiones autenticadas con token pasen una comprobación autoritativa equivalente, o desactive la ruta del token cuando la política exija una decisión en cada conexión.
No lo compense aceptando todos los tokens sin condiciones. Un token caducado o inválido sigue teniendo que fallar, y debe fallar por el mismo punto de decisión que todo lo demás.
Vincule la reserva a una instancia, no a una dirección
Una dirección es una identidad pobre: una reconexión desde el mismo portátil puede llegar desde otra dirección, y una credencial copiada puede llegar desde la misma. Vincule la reserva a la instancia de cliente que asigna el servidor, de modo que una reautenticación de la instancia ya admitida se reconozca como propietaria. Un identificador de instancia nuevo tiene que adquirir su propia ranura mediante la decisión de gana el primero, incluso cuando presenta el mismo token.
Libere solo la reserva del intento que falló. Un evento de desconexión retrasado de un intento anterior no debe borrar la ranura de un propietario más nuevo, y por eso la liberación nombra la instancia y no la cuenta. Tras reiniciarse el controlador, concilie las sesiones activas antes de admitir a nadie, y aplique la misma regla en cada puerta de enlace que sirva la cuenta.
Decida por separado cómo se recupera una ranura realmente obsoleta. El administrador necesita una forma documentada de limpiarla, y esa ruta no debería ser accesible para un usuario que simplemente hace clic en reconectar.
Pruebe los pares que importan: dos inicios de sesión casi simultáneos, una reconexión tras un cierre limpio, una reautenticación de la sesión existente, un recién llegado rechazado y un reinicio del controlador. En todos los casos la sesión existente debe seguir siendo utilizable y el recién llegado debe ser rechazado sin daños colaterales a otras cuentas.