Gaña a primeira sesión: restrinxir os inicios de sesión de OpenVPN antes do desaloxo
Rexeitar un inicio de sesión posterior non é o mesmo que substituír o anterior. A decisión debe tomarse antes do desaloxo do mesmo nome, e a comprobación da ranura ten que ser atómica.
Unha política que permite unha sesión por conta parece resolta ata que chega o segundo inicio de sesión. Son posibles dous desenlaces: o recén chegado substitúe a sesión existente, ou a sesión existente conserva a ranura e o recén chegado é rexeitado. Só o segundo é unha política de gaña a primeira sesión. A opción de cliente á que recorre a maioría activa a concorrencia e, polo tanto, non a produce.
Dous contratos agóchanse detrás dun só axuste
Coa concorrencia desactivada, unha segunda conexión que presente o mesmo nome de certificado pode desprazar a sesión que xa está en marcha. Activar a concorrencia permite varias sesións á vez, que é o contrario dun límite. Ningún dos dous estados é unha política de rexeitamento, así que a decisión debe tomarse noutro sitio por completo.
Escriba o contrato antes de implementar nada: quen é rexeitado, que evidencia identifica a sesión existente e que ocorre cando unha sesión morre sen unha desconexión limpa. Unha política que ninguén formulou así non se pode probar despois.
O desaloxo chega antes do seu gancho de conexión
Na ruta de código do servidor 2.6, a preparación temperá dun cliente novo elimina as instancias existentes co mesmo nome cando a concorrencia está desactivada. Esa eliminación ocorre antes de que se execute a cadea de manexadores de conexión. Por iso un script que detecta o duplicado e devolve un fallo rexeita o recén chegado despois de que a sesión existente xa fose expulsada, xusto o resultado que a política pretendía evitar. A orde das chamadas de retorno na implementación upstream é a única resposta fiable para a súa 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 |
Sondar o ficheiro de estado tampouco é unha porta. Dous intentos que chegan á vez poden ver ambos unha ranura baleira antes de que ningún a confirme, e ambos continúan.
Leve a decisión á autenticación
A interface de administración pode asumir a decisión de autenticación tras verificar o certificado. Nesa disposición o controlador non é un monitor: recibe cada instancia de cliente que se conecta e responde se esa instancia pode continuar. Como a resposta chega antes do establecemento, un rexeitamento deixa intacta a sesión existente. A mesma canle informa das desconexións, e así o controlador sabe que unha ranura se liberou lexitimamente.
Toda instancia nova debe pasar esa porta, incluídas as reconexións e calquera ruta que se reautentique sen aviso. Unha porta á que algunhas instancias nunca chegan non protexe nada, e a omisión permanece invisible ata que alguén proba o atallo.
Os tokens poden pasar de longo pola porta
Unha vez emitido un token, o servidor pode validalo internamente e omitir a autenticación externa para esa conexión. A chamada de administración nunca ocorre, así que unha comprobación de ranura implementada só alí nunca ve a instancia nova. Ese comportamento é unha comodidade para os usuarios e un burato para unha política de concorrencia. Faga que as conexións autenticadas con token pasen unha comprobación autoritativa equivalente, ou desactive a ruta do token cando a política esixa unha decisión en cada conexión.
Non o compense aceptando todos os tokens sen condicións. Un token caducado ou inválido segue tendo que fallar, e debe fallar polo mesmo punto de decisión que todo o demais.
Vincule a reserva a unha instancia, non a un enderezo
Un enderezo é unha identidade pobre: unha reconexión desde o mesmo portátil pode chegar desde outro enderezo, e unha credencial copiada pode chegar desde o mesmo. Vincule a reserva á instancia de cliente que asigna o servidor, de modo que unha reautenticación da instancia xa admitida se recoñeza como propietaria. Un identificador de instancia novo ten que adquirir a súa propia ranura mediante a decisión de gaña o primeiro, mesmo cando presenta o mesmo token.
Libere só a reserva do intento que fallou. Un evento de desconexión atrasado dun intento anterior non debe borrar a ranura dun propietario máis novo, e por iso a liberación nomea a instancia e non a conta. Tras reiniciarse o controlador, concilie as sesións activas antes de admitir a ninguén, e aplique a mesma regra en cada pasarela que sirva a conta.
Decida por separado como se recupera unha ranura realmente obsoleta. O administrador necesita unha forma documentada de limpala, e esa ruta non debería ser accesible para un usuario que simplemente fai clic en reconectar.
Probe os pares que importan: dous inicios de sesión case simultáneos, unha reconexión tras un peche limpo, unha reautenticación da sesión existente, un recén chegado rexeitado e un reinicio do controlador. En todos os casos a sesión existente debe seguir sendo utilizábel e o recén chegado debe ser rexeitado sen danos colaterais para outras contas.