Esdeveniments de ganxo d’OpenVPN: per què el nom i la marca de temps no són una clau

Un registre de desconnectació arriba després que ja hagi començat una segona connexió amb el mateix nom, i un gestor que actualitza la fila més recent d’aquest usuari tanca la sessió equivocada. L’error no és la comparació de marques de temps. És el supòsit que un nom més un segon sencer identifiquen una sessió. Els esdeveniments de ganxo descriuen connexions, i una connexió necessita una clau que li sigui pròpia.

Comenceu pel que signifiquen realment les variables de desconnectació. Només llavors té sentit l’elecció de l’identificador.

Què porta realment el ganxo de desconnectació

A Community OpenVPN 2.6, la referència dels ganxos time_unix defineix com el moment en què el client es va connectar; s’estableix abans que s’executi el ganxo de connexió i no es redefineix quan més tard s’activa el ganxo de desconnectació. time_duration dóna la durada d’aquella sessió en segons, de manera que el final és aproximadament l’hora de connexió més la durada. Tots dos són segons sencers, i cap dels dos no és el moment en què la vostra base de dades va processar l’esdeveniment. Mantenir aquests tres temps separats és el que fa que una correlació es mantingui en lloc de només semblar correcta durant les proves.

Aquesta aritmètica mereix ser escrita, perquè és l’únic temps de final que ofereix el mateix ganxo. El retard de processament i les diferències de rellotge entre amfitrions encara queden fora.

Per què la parella òbvia no és única

Aparellar el nom amb l’hora de connexió estreny la cerca i encara no identifica una sessió. Un client es pot tornar a connectar dins del mateix segon, de manera que dues sessions poden compartir tots dos valors. Dues instàncies del dimoni, o una substitució de servidor que manté la mateixa configuració, poden produir aquesta parella des de processos diferents. Les adreces de túnel es reciclen pel mateix motiu, cosa que les converteix en atributs d’una sessió més que en identificadors d’una.

El mode de fallada és silenciós. Una desconnectació tardana de la primera sessió coincideix amb la fila més recent i retira una assignació que la segona sessió encara fa servir, de manera que l’usuari pateix una pèrdua d’accés aleatòria que no ha provocat. Un recompte de files que després sembla correcte fa que el problema sigui més difícil de detectar.

D’on ve una identitat estable

La interfície de gestió assigna a cada client un identificador d’instància de client, i aquest identificador està limitat a la instància del dimoni que el va emetre. Una clau externa viable combina un identificador de servidor estable, una època que canvia quan arrenca el dimoni i aquest ID de client. L’època importa perquè els identificadors es reinicien amb el procés, i un ID de procés nu pot ser reutilitzat més tard per una cosa no relacionada.

Les variables d’entorn definides dins d’un script de connexió fill no viatgen cap a l’script de desconnectació posterior del dimoni pare, perquè aquests scripts s’executen com a processos separats amb entorns propis. Per tant, generar un UUID en el moment de la connexió és mitja solució. El costat de la desconnectació ha de poder anomenar el mateix UUID, cosa que significa que la identitat ha de viure en un lloc on tots dos esdeveniments puguin arribar.

Feu la retirada condicional i idempotent

Retireu per propietari de sessió, no per usuari. Un gestor que esborra qualsevol assignació que actualment pertany a un nom finalment esborrarà l’equivocada, i l’única defensa és comprovar que el registre que s’elimina és el registre que descriu aquest esdeveniment.

La interfície de gestió accepta un sol client de gestió connectat alhora, així que integreu-vos amb qui ja la posseeix en lloc d’adjuntar un segon observador que competeix pel mateix sòcol.

Gestioneu els esdeveniments repetits sense canviar el resultat dues vegades, i conserveu els esdeveniments no aparellats per a la reconciliació en lloc de descartar-los. Una devolució de trucada de desconnectació té condicions de cicle de vida documentades i pot no arribar mai després d’un error greu o una aturada forçada, així que el disseny necessita una manera de representar una sessió a la qual falta l’esdeveniment final.

Proveu els casos incòmodes a propòsit: dues reconnexions dins d’un segon, dues instàncies del dimoni, una connexió el processament de la qual ha fallat i un reinici del dimoni enmig d’una sessió. Una clau que sobreviu a tots quatre és una clau digna de confiança.