Reconectar un cliente OpenVPN: tres controis, tres ámbitos

Alguén pide que se reconecte o cliente VPN, e esa petición pode significar tres cousas distintas. Pode significar descartar unha sesión autenticada, avisar todos os clientes de que un servidor UDP se marcha ou reiniciar o propio daemon. Cada unha ten un radio de impacto distinto, e escoller a incorrecta converte unha reparación para un usuario nunha caída. O alcance é a decisión, e o comando derívase del.

Pregunte a quen debe afectar antes de preguntar que control usar.

Unha instancia: a interface de xestión

Unha interface de xestión configurada pode listar as instancias conectadas e descartar exactamente unha delas. Cada sesión leva un identificador de cliente, e client-kill CID apunta a ese identificador en lugar dun nome común. Lea o identificador vivo da saída de estado actual, porque un valor copiado dun rexistro antigo refírese a unha sesión que xa non existe. Descartar a instancia remata esa conexión e nada máis.

Non garante unha conexión nova. Que o cliente volva depende da súa configuración de reintentos, das entradas remotas que lle quedan, dos seus requisitos de autenticación e de se a aplicación supervisora segue en execución. Un cliente que volve obtén un identificador novo, e por iso comparar identificadores é a única forma fiable de distinguir o vello do novo.

Un aviso de saída UDP non é unha orde por cliente

explicit-exit-notify é unha directiva de configuración sobre eventos de saída e reinicio. Nun cliente UDP indica ao par que a sesión remata, e o argumento numérico controla cantas veces se reintenta o aviso. Cando o servidor funciona sobre UDP envía unha mensaxe de control de reinicio aos seus clientes conectados, e os valores documentados distinguen reconectar ao mesmo servidor de pasar a outra entrada remota. É un sinal de ciclo de vida cunha audiencia ampla.

Nada nel selecciona un cliente arbitrario nun momento arbitrario. Tratalo como un botón de reconexión chega a todas as sesións conectadas á vez.

Os sinais actúan sobre o proceso, non sobre unha sesión

SIGUSR1 pide a un proceso en execución que reinicie a súa conexión sen reler a configuración, e as opcións de persistencia deciden que sobrevive a ese reinicio. SIGHUP vai máis alá: rele o ficheiro de configuración e reabre os seus recursos. SIGTERM e SIGINT piden un apagado ordenado. Son operacións a nivel de proceso: nun servidor con varios clientes afectan cada sesión que o proceso transporta, non a que aparece no ticket.

Cando o proceso se executa baixo un xestor de servizos, use o control propio do xestor en lugar de enviar un sinal a un PID que atopou nunha lista de procesos. Lea a unidade para ver que sinal envía o xestor, porque un reinicio e unha recarga fan cousas distintas ao mesmo daemon.

Decida o alcance antes de escoller o control

Tres preguntas o resolven. A quen debe afectar: a un usuario, a cada cliente dun servidor ou ao daemon e todo o que transporta. Que debe sobrevivir: a configuración, o estado do túnel ou nada. Quen está autorizado: a integración de xestión, o propietario do servizo ou o operador de rede que controla o aviso de saída. Responda iso e só encaixa un control.

Engadir un escoitador de control sen autenticar para obter un botón de reconexión entrega a quen poida alcanzar o porto moito máis que ese botón.

Verifique a sesión nova, non a desconexión

Un evento de desconexión demostra que a sesión antiga rematou. Non di nada sobre unha nova que se autentique, reciba un enderezo, instale rutas ou alcance o recurso que o usuario necesitaba. Comprobe o identificador novo, despois o estado do túnel, despois un recurso real. Eses tres pasos son a diferenza entre unha reconexión e unha conexión que funciona.

Escriba o alcance no rexistro de cambios. «Reconectei o cliente» non é unha descrición cando o cliente era un de corenta nun servidor compartido.