Socket de xestión de OpenVPN: unha canle de control, non métricas

Pida un estado á interface de xestión unha vez e comeza a parecer un porto de estado. Non o é. Unha vez admitido un cliente, pode emitir as ordes de control do protocolo, e a conta que executa ese cliente herda todo o que esas ordes poden facerlle ao daemon. Tratalo como un fluxo de só lectura é o erro que converte unha integración de monitorización nunha consola sen autenticación.

A crenza, e o que custa

A crenza é que o oínte de xestión equivale a un punto final de métricas: conecte un recolledor, lea os contadores e siga adiante. O que ocorre en realidade é que o recolledor abre unha sesión con capacidades de control, e calquera outra suposición que fixese sobre o despregamento agora depende de que ese recolledor se comporte ben.

Nada na interface anuncia un modo de só lectura. Non hai ningún rol de observador que escoller, e un nome de usuario na configuración non crea un.

Que ten realmente un cliente admitido

O daemon da comunidade acepta un só cliente de xestión activo á vez. Ese único espazo significa que unha GUI, un script e un axente de monitorización non poden conectarse todos; o segundo espera ou falla mentres o primeiro mantén a sesión. Se o seu deseño asume lectores simultáneos, xa está equivocado.

Onde abonda unha instantánea periódica, a saída do ficheiro de estado dálle os mesmos números sen unha sesión activa. Escribir ese ficheiro a intervalos e lelo con permisos de ficheiro ordinarios mantén o recolledor completamente fóra do plano de control, e esa é a disposición que a maioría da monitorización necesita de verdade.

Un socket propio, non un aberto

Un socket de dominio Unix mantén a ruta de control fóra da rede, o que elimina do problema o enderezo cambiante do túnel. Non elimina a cuestión dos permisos. O directorio pai ten que ser escribible pola conta do servizo e accesible pola conta do controlador, e eses son dous permisos separados:

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

O ficheiro de contrasinal leva o segredo de xestión na súa primeira liña. Protexa ese ficheiro como calquera outra credencial e manteña o seu contido fóra dos rexistros e dos tíckets de soporte. As restricións de usuario e grupo son comprobacións de igual no socket Unix, non permisos do sistema de ficheiros, así que o proceso previsto necesita tanto o acceso ao ficheiro como a identidade correspondente.

Facer o socket accesible para todo o mundo para resolver un erro de permisos é o único arranxo que hai que evitar. Converte unha canle de control local en algo que calquera proceso do host pode manexar.

Publicalo por TCP non é o mesmo deseño

Mover o oínte a un porto TCP non o fai máis seguro nin máis cómodo. A contrasinal de xestión envíase en claro, así que un oínte TCP expón tanto a credencial como a sesión a calquera que poida observar a ruta. Chegar a el desde outro host require unha canle de administración autorizada, ou un pequeno axente local que expoña só as observacións que necesita.

Unha contrasinal sobre un transporte en texto claro é autenticación sen confidencialidade, e esa combinación é peor do que parece porque se sente protexida.

Dependencias de arranque que non pediu

Varias opcións de xestión cambian o ciclo de vida do daemon. Manter o arranque ata que se conecte un controlador, ou rematar cando o controlador desaparece, converte un observador opcional nunha dependencia dura. Un axente de monitorización que caese levaría entón o túnel consigo.

Revise esas opcións antes de habilitar nada máis aló do propio socket. A observación opcional debe seguir sendo opcional, e unha política de reinicio non debería acoplarse a un recolledor engadido para as gráficas.

Un ficheiro de socket que queda tras un proceso fallido non é proba de que exista un oínte. Identifique que instancia posúe a ruta antes de eliminarla, e use o fluxo de recuperación propio do servizo en lugar de borrar ficheiros baixo un daemon en execución.

Como se ve a aceptación

Catro comprobacións cobren o deseño: a identidade prevista do controlador conéctase, un proceso sen esa identidade é rexeitado, o daemon sobrevive a un controlador que se desconecta sen aviso, e o túnel segue levando tráfico tras un reinicio controlado. Unha conexión de xestión correcta demostra só o plano de control. Non di nada sobre se funciona o tráfico de aplicacións privadas, así que probeo por separado. Anote os catro resultados onde o seguinte operador poida atopalos.

A documentación da interface de xestión describe o modelo dun só cliente e a natureza privilexiada do protocolo, e esa é a parte que paga a pena ler antes de apuntarlle un panel.