Só un cliente de xestión: por que o teu monitor expulsa a interface gráfica
O socket de xestión acepta unha conexión á vez. Un segundo subscritor ou non consegue conectarse ou rouba o control ao compoñente que posúe os avisos.
Unha interface gráfica de escritorio mantén a conexión de xestión, así que un script de monitorización que tenta abrir a súa non le nada ou, peor, a interface deixa de responder aos avisos. A conclusión habitual é que o daemon é inestable. No daemon da comunidade a limitación é deliberada: a interface de control serve un único cliente de xestión conectado á vez, e ese número non ten nada que ver con cantos usuarios pode levar a VPN.
Un socket, un titular
A canle de xestión acepta un único cliente conectado. Cando chega un segundo mentres o primeiro está activo, espera ou é rexeitado, e non hai ningún modo de subscritor paralelo agochado tras unha opción. Desconectar o titular actual permite ao daemon aceptar o seguinte, e iso é unha transferencia, non unha segunda canle.
Iso converte cada ferramenta adicional nunha competidora. Se a interface posúe a conexión, un script de sondaxe ou non se conecta ou só o consegue despois de que a interface renunciou, e a secuencia repítese na seguinte reconexión. Se o script se conecta primeiro, a interface perde o seu camiño de control e os seus avisos deixan de funcionar. Ningunha das ferramentas informa do conflito, porque cada unha só ve a súa propia orde fallida.
| What you need | Mechanism that fits | What it cannot do |
|---|---|---|
| Periodic list of connected clients | Status file written on an interval | Deliver events as they happen |
| Interactive prompts and session control | The single management connection | Serve two controllers at once |
| Multiple consumers of either | One owner process that fans out | Exist without you writing it |
Decidide que compoñente posúe o control
Escollede un único titular para a canle interactiva e deixade que sexa o único que se conecta. Unha interface que xestiona a conexión, un script que responde aos avisos de autenticación e un controlador que remata sesións contan todos como titulares, e só un pode ocupar o papel.
Cando unha interface posúe a conexión, usade a integración que ofrece en lugar de loitar con ela. Competir co titular polo socket produce fallos intermitentes que aos usuarios lles parecen aleatorios, e quen depura normalmente só ve a segunda metade da carreira. Anotade que proceso se conecta primeiro tras un reinicio, porque esa orde decide cada vez quen gaña. Un monitor que arrinca antes que a interface manterá a canle ata que a interface renuncie.
Usade instantáneas de estado para os recollectores
A maior parte da monitorización necesita unha lista, non unha conversa. Un ficheiro de estado periódico responde a iso sen tocar a canle de control, e segue funcionando mentres a interface permanece conectada.
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixO intervalo é o orzamento de frescura, así que axustádeo ao que o panel necesita de verdade e non ao valor máis pequeno que pareza seguro. Unha instantánea escrita cada poucos segundos é barata; un script que se reconecta ao socket de control cada poucos segundos non o é, porque cada reconexión compite co titular.
Unha instantánea non é un historial nin un fluxo de eventos. As conexións que chegan e marchan dentro dun mesmo intervalo nunca aparecen, así que un requisito de auditoría non se pode satisfacer sondando un ficheiro que se sobrescribe a si mesmo. Se precisades saber se un usuario se conectou, aínda que sexa unha vez, a instantánea é o instrumento equivocado.
A difusión é un deseño, non un modo
Se varios consumidores necesitan de verdade datos de xestión en directo, poñede un único compoñente de confianza diante do socket e deixade que publique observacións estritamente escollidas para os demais. Ese compoñente posúe a reconexión, os avisos de autenticación e a decisión sobre que é seguro expor.
Construídeo deliberadamente: definide que consultas están permitidas, rexistrade quen as pediu e evitade que a capa de difusión se converta por accidente nun panel de control remoto. O daemon non ten ningún modo multicliente para activar, e ningunha liña de configuración crea un. Tratade o titular como parte da fronteira de seguridade, porque sostén unha interface que pode desconectar persoas. Reinicialo debería ser unha operación rutineira cun camiño de recuperación documentado.
Tratade o socket como privilexio, non como métricas
A interface de xestión pode desconectar usuarios, cambiar o estado e ler eventos que nomean persoas. O seu contrasinal autentica o cliente e non cifra o transporte, así que un oínte de rede expón a conversa a calquera que a poida observar.
Preferide un socket local ou un oínte estritamente restrinxido, e comprobade a que proceso se dirixe realmente o voso recollector, xa que os produtos de servidor traen as súas propias API de xestión que se comportan distinto. Un recollector apuntado ao daemon equivocado produce conclusións seguras e erróneas. Confirmade o camiño e o proceso propietario antes de depurar unha consulta que non devolve nada.