Eventos de gancho de OpenVPN: por que o nome e a marca de tempo non son unha clave

Un rexistro de desconexión chega despois de que xa comezase unha segunda conexión co mesmo nome, e un manexador que actualiza a fila máis recente dese usuario pecha a sesión equivocada. O erro non é a comparación de marcas de tempo. É a suposición de que un nome máis un segundo enteiro identifican unha sesión. Os eventos de gancho describen conexións, e unha conexión necesita unha clave que lle pertenza só a ela.

Comece polo que significan realmente as variables de desconexión. Só entón ten sentido a elección do identificador.

Que transporta realmente o gancho de desconexión

En Community OpenVPN 2.6, a referencia de ganchos time_unix define como o momento en que se conectou o cliente; establécese antes de que se execute o gancho de conexión e non se redefine cando o gancho de desconexión se activa despois. time_duration dá a duración desa sesión en segundos, así que o final é aproximadamente a hora de conexión máis a duración. Ambos son segundos enteiros, e ningún é o momento en que a súa base de datos procesou o evento. Manter eses tres tempos separados é o que fai que unha correlación se manteña en lugar de só parecer correcta durante as probas.

Esta aritmética merece escribirse, porque é o único tempo de finalización que ofrece o propio gancho. O atraso de procesamento e as diferenzas de reloxo entre hosts seguen quedando fóra.

Por que o par obvio non é único

Emparellar o nome coa hora de conexión reduce a busca e segue sen identificar unha sesión. Un cliente pode reconectarse dentro do mesmo segundo, así que dúas sesións poden compartir ambos os valores. Dúas instancias do demonio, ou unha substitución de servidor que conserva a mesma configuración, poden producir ese par desde procesos distintos. Os enderezos de túnel recíclanse polo mesmo motivo, o que os converte en atributos dunha sesión máis que en identificadores dunha.

O modo de fallo é silencioso. Unha desconexión tardía da primeira sesión coincide coa fila máis recente e retira unha asignación que a segunda sesión aínda usa, así que o usuario experimenta unha perda de acceso aleatoria que non provocou. Un reconto de filas que despois parece correcto fai que o problema sexa máis difícil de detectar.

De onde vén unha identidade estable

A interface de administración asigna a cada cliente un identificador de instancia de cliente, e ese identificador está limitado á instancia do demonio que o emitiu. Unha clave externa viable combina un identificador de servidor estable, unha época que cambia cando arranca o demonio e ese ID de cliente. A época importa porque os identificadores se reinician co proceso, e un ID de proceso espido pode reutilizarse máis tarde por algo non relacionado.

As variables de contorno definidas dentro dun script de conexión fillo non viaxan ao script de desconexión posterior do demonio pai, porque eses scripts se executan como procesos separados cos seus propios contornos. Por iso, xerar un UUID no momento da conexión é media solución. O lado da desconexión ten que poder nomear o mesmo UUID, o que significa que a identidade debe vivir nun lugar ao que poidan chegar ambos os eventos.

Faga a retirada condicional e idempotente

Retire por propietario de sesión, non por usuario. Un manexador que elimina calquera asignación que actualmente pertenza a un nome acabará eliminando a equivocada, e a única defensa é comprobar que o rexistro que se elimina é o rexistro que describe este evento.

A interface de administración acepta un só cliente de administración conectado á vez, así que intégrese con quen xa a posúe en lugar de engadir un segundo observador que compita polo mesmo socket.

Xestione eventos repetidos sen cambiar o resultado dúas veces, e conserve os eventos non emparellados para a reconciliación en lugar de descartalos. Unha devolución de chamada de desconexión ten condicións de ciclo de vida documentadas e pode non chegar nunca tras un fallo ou unha parada forzada, así que o deseño necesita unha forma de representar unha sesión cuxo evento final falta.

Probe os casos incómodos a propósito: dúas reconexións dentro dun segundo, dúas instancias do demonio, unha conexión cuxo procesamento fallou e un reinicio do demonio no medio dunha sesión. Unha clave que sobrevive aos catro é unha clave digna de confianza.