Socket de gestió d’OpenVPN: un canal de control, no mètriques

Demaneu un estat a la interfície de gestió una vegada i comença a semblar un port d’estat. No ho és. Quan un client és admès, pot emetre les ordres de control del protocol, i el compte que executa aquest client hereta tot el que aquestes ordres poden fer al dimoni. Tractar-la com un flux de només lectura és l’error que converteix una integració de monitoratge en una consola sense autenticació.

La creença, i què costa

La creença és que l’oient de gestió equival a un punt final de mètriques: connecteu un recol·lector, llegiu els comptadors i continueu. El que passa en realitat és que el recol·lector obre una sessió amb capacitats de control, i qualsevol altra suposició que hàgiu fet sobre el desplegament ara depèn que aquest recol·lector es comporti bé.

Res de la interfície no anuncia un mode de només lectura. No hi ha cap rol d’observador per triar, i un nom d’usuari a la configuració no en crea cap.

Què té realment un client admès

El dimoni de la comunitat accepta un sol client de gestió actiu alhora. Aquest únic espai significa que una GUI, un script i un agent de monitoratge no poden connectar-se tots alhora; el segon espera o falla mentre el primer manté la sessió. Si el vostre disseny suposa lectors simultanis, ja és incorrecte.

On n’hi ha prou amb una instantània periòdica, la sortida del fitxer d’estat us dóna els mateixos números sense una sessió activa. Escriure aquest fitxer a intervals i llegir-lo amb permisos de fitxer ordinaris manté el recol·lector completament fora del pla de control, que és la disposició que la majoria de monitoratge necessita de debò.

Un socket propi, no un d’obert

Un socket de domini Unix manté el camí de control fora de la xarxa, cosa que elimina del problema l’adreça canviant del túnel. No elimina la qüestió dels permisos. El directori pare ha de ser escribible pel compte del servei i accessible pel compte del controlador, i aquests són dos permisos separats:

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

El fitxer de contrasenya porta el secret de gestió a la seva primera línia. Protegiu aquest fitxer com qualsevol altra credencial i manteniu-ne el contingut fora dels registres i dels tiquets de suport. Les restriccions d’usuari i de grup són comprovacions d’igual a Unix socket, no permisos del sistema de fitxers, així que el procés previst necessita tant l’accés al fitxer com la identitat corresponent.

Fer el socket accessible a tot el món per resoldre un error de permisos és l’únic pedaç que cal evitar. Converteix un canal de control local en una cosa que qualsevol procés de l’amfitrió pot conduir.

Publicar-lo per TCP no és el mateix disseny

Moure l’oient a un port TCP no el fa més segur ni més còmode. La contrasenya de gestió s’envia en clar, així que un oient TCP exposa tant la credencial com la sessió a qualsevol que pugui observar el camí. Arribar-hi des d’un altre amfitrió requereix un canal d’administració autoritzat, o un petit agent local que només exposi les observacions que necessiteu.

Una contrasenya sobre un transport en text clar és autenticació sense confidencialitat, i aquesta combinació és pitjor del que sembla perquè fa la sensació d’estar protegida.

Dependències d’arrencada que no heu demanat

Diverses opcions de gestió canvien el cicle de vida del dimoni. Retenir l’arrencada fins que es connecti un controlador, o acabar quan el controlador desapareix, converteix un observador opcional en una dependència dura. Un agent de monitoratge que es pengés llavors s’enduria el túnel amb ell.

Reviseu aquestes opcions abans d’habilitar res més enllà del mateix socket. L’observació opcional ha de continuar sent opcional, i una política de reinici no s’ha d’acoblar a un recol·lector afegit per als gràfics.

Un fitxer de socket que queda després d’un procés fallit no és prova que existeixi un oient. Identifiqueu quina instància posseeix el camí abans de suprimir-lo, i feu servir el flux de recuperació propi del servei en lloc d’esborrar fitxers sota un dimoni en marxa.

Com es veu l’acceptació

Quatre comprovacions cobreixen el disseny: la identitat prevista del controlador es connecta, un procés sense aquesta identitat és rebutjat, el dimoni sobreviu a un controlador que es desconnecta sense avís, i el túnel encara porta trànsit després d’un reinici controlat. Una connexió de gestió correcta només demostra el pla de control. No diu res sobre si funciona el trànsit d’aplicacions privades, així que proveu-ho a part. Anoteu els quatre resultats on el proper operador els pugui trobar.

La documentació de la interfície de gestió descriu el model d’un sol client i la naturalesa privilegiada del protocol, i aquesta és la part que val la pena llegir abans d’apuntar-hi un tauler.