Vince la prima sessione: filtrare gli accessi OpenVPN prima dello sgombero

Una politica che consente una sessione per account sembra risolta finché non arriva il secondo accesso. Sono possibili due esiti: il nuovo arrivato sostituisce la sessione in corso, oppure la sessione in corso conserva lo slot e il nuovo arrivato viene rifiutato. Solo il secondo è una politica in cui vince la prima sessione. L’opzione client a cui ricorre la maggior parte delle persone abilita la concorrenza e quindi non la produce.

Due contratti si nascondono dietro un’unica impostazione

Con la concorrenza disattivata, una seconda connessione che presenta lo stesso nome di certificato può spostare la sessione già in esecuzione. Attivare la concorrenza consente più sessioni contemporaneamente, cioè l’opposto di un limite. Nessuno dei due stati è una politica di rifiuto, quindi la decisione va presa altrove.

Scrivete il contratto prima di implementare qualsiasi cosa: chi viene rifiutato, quale prova identifica la sessione in corso e cosa accade quando una sessione muore senza una disconnessione pulita. Una politica che nessuno ha formulato così non può essere verificata in seguito.

Lo sgombero avviene prima del vostro hook di connessione

Nel percorso di codice del server 2.6, la preparazione iniziale di un nuovo client rimuove le istanze esistenti con lo stesso nome quando la concorrenza è disattivata. Tale rimozione avviene prima che venga eseguita la catena dei gestori di connessione. Uno script che nota il duplicato e restituisce un errore rifiuta quindi il nuovo arrivato dopo che la sessione in corso è già stata espulsa, esattamente l’esito che la politica doveva evitare. L’ordine delle callback nell’implementazione upstream è l’unica risposta affidabile per la vostra build.

Anche interrogare il file di stato non è una porta. Due tentativi che arrivano insieme possono entrambi vedere uno slot vuoto prima che uno dei due lo confermi, e proseguono entrambi.

Spostate la decisione nell’autenticazione

L’interfaccia di gestione può assumere la decisione di autenticazione dopo la verifica del certificato. In questa disposizione il controller non è un monitor: riceve ogni istanza di client che si connette e risponde se quell’istanza può procedere. Poiché la risposta arriva prima dell’instaurazione, un rifiuto lascia intatta la sessione in corso. Lo stesso canale segnala le disconnessioni, ed è così che il controller apprende che uno slot è stato liberato legittimamente.

Ogni nuova istanza deve superare quella porta, comprese le riconnessioni e qualsiasi percorso che si riautentichi senza richiesta. Una porta che alcune istanze non raggiungono mai non protegge nulla, e l’omissione resta invisibile finché qualcuno non prova la scorciatoia.

I token possono passare oltre la porta

Una volta emesso un token, il server può convalidarlo internamente e saltare l’autenticazione esterna per quella connessione. La chiamata di gestione non avviene mai, quindi un controllo dello slot implementato solo lì non vede mai la nuova istanza. Questo comportamento è una comodità per gli utenti e un buco per una politica di concorrenza. Fate passare le connessioni autenticate con token da un controllo autorevole equivalente, oppure disattivate il percorso del token quando la politica richiede una decisione su ogni connessione.

Non compensatelo accettando ogni token senza condizioni. Un token scaduto o non valido deve comunque fallire, e deve fallire attraverso lo stesso punto di decisione di tutto il resto.

Legate la prenotazione a un’istanza, non a un indirizzo

Un indirizzo è un’identità debole: una riconnessione dallo stesso portatile può arrivare da un altro indirizzo, e una credenziale copiata può arrivare dallo stesso. Legate la prenotazione all’istanza di client che il server assegna, così che una riautenticazione dell’istanza già ammessa venga riconosciuta come proprietaria. Un nuovo identificatore di istanza deve acquisire il proprio slot tramite la decisione del primo che vince, anche quando presenta lo stesso token.

Liberate solo la prenotazione appartenente al tentativo fallito. Un evento di disconnessione ritardato di un tentativo più vecchio non deve cancellare lo slot di un proprietario più recente, ed è per questo che il rilascio nomina l’istanza e non l’account. Dopo il riavvio del controller, riconciliate le sessioni attive prima di ammettere chiunque, e applicate la stessa regola su ogni gateway che serve l’account.

Decidete separatamente come viene recuperato uno slot davvero obsoleto. Un amministratore ha bisogno di un modo documentato per ripulirlo, e quel percorso non dovrebbe essere raggiungibile da un utente che si limita a fare clic su riconnetti.

Provate le coppie che contano: due accessi quasi simultanei, una riconnessione dopo una chiusura pulita, una riautenticazione della sessione in corso, un nuovo arrivato rifiutato e un riavvio del controller. In ogni caso la sessione in corso deve restare utilizzabile e il nuovo arrivato deve essere rifiutato senza danni collaterali per gli altri account.