Socketul de administrare OpenVPN: un canal de control, nu metrici

Cereți o dată starea interfeței de administrare și începe să arate ca un port de stare. Dar nu este. Odată ce un client este admis, poate emite comenzile de control ale protocolului, iar contul care rulează acel client moștenește tot ce pot face aceste comenzi demonului. Tratarea lui ca un flux doar-citire este greșeala care transformă o integrare de monitorizare într-o consolă fără autentificare.

Convingerea, și cât costă

Convingerea este că ascultătorul de administrare este echivalent cu un punct final de metrici: atașați un colector, citiți contoarele, mergeți mai departe. De fapt, colectorul deschide o sesiune cu capabilități de control, iar orice altă presupunere făcută despre implementare depinde acum de comportamentul bun al acelui colector.

Nimic din interfață nu anunță un mod doar-citire. Nu există niciun rol de observator de ales, iar un nume de utilizator din configurație nu creează unul.

Ce deține de fapt un client admis

Demonul comunității acceptă un singur client de administrare activ o dată. Acest singur slot înseamnă că o interfață grafică, un script și un agent de monitorizare nu se pot conecta toate; al doilea așteaptă sau eșuează în timp ce primul ține sesiunea. Dacă proiectul dumneavoastră presupune cititori simultani, este deja greșit.

Acolo unde un instantaneu periodic este suficient, ieșirea fișierului de stare vă dă aceleași numere fără o sesiune activă. Scrierea acelui fișier la intervale și citirea lui cu permisiuni obișnuite de fișier ține colectorul complet în afara planului de control, iar aceasta este aranjamentul de care majoritatea monitorizării are de fapt nevoie.

Un socket propriu, nu unul deschis

Un socket de domeniu Unix ține calea de control în afara rețelei, ceea ce elimină din problemă adresa schimbătoare a tunelului. Nu elimină întrebarea permisiunilor. Directorul părinte trebuie să fie scriibil de contul serviciului și accesibil de contul controlerului, iar acestea sunt două permisiuni separate:

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

Fișierul de parolă poartă secretul de administrare pe primul său rând. Protejați acel fișier ca orice altă acreditare și țineți conținutul lui departe de jurnale și de tichetele de asistență. Restricțiile de utilizator și grup sunt verificări de partener pe socketul Unix, nu permisiuni ale sistemului de fișiere, așa că procesul dorit are nevoie atât de accesul la fișier, cât și de identitatea potrivită.

A face socketul accesibil lumii întregi pentru a elimina o eroare de permisiuni este singura corectură de evitat. Transformă un canal de control local în ceva ce orice proces de pe gazdă poate conduce.

Publicarea prin TCP nu este același proiect

Mutarea ascultătorului pe un port TCP nu îl face mai sigur sau mai comod. Parola de administrare este trimisă în clar, așa că un ascultător TCP expune atât acreditarea, cât și sesiunea oricui poate observa calea. A ajunge la el de pe altă gazdă necesită un canal de administrare autorizat sau un mic agent local care expune doar observațiile de care aveți nevoie.

O parolă pe un transport în clar este autentificare fără confidențialitate, iar combinația aceasta este mai rea decât pare pentru că se simte protejată.

Dependențe de pornire pe care nu le-ați cerut

Mai multe opțiuni de administrare schimbă ciclul de viață al demonului. A ține pornirea până când se conectează un controler sau a termina când controlerul dispare transformă un observator opțional într-o dependență dură. Un agent de monitorizare care se prăbușește ar lua atunci tunelul cu el.

Examinați acele opțiuni înainte de a activa orice dincolo de socketul propriu-zis. Observarea opțională ar trebui să rămână opțională, iar o politică de repornire nu ar trebui cuplată cu un colector adăugat pentru grafice.

Un fișier de socket rămas după un proces eșuat nu este dovada că există un ascultător. Identificați ce instanță deține calea înainte de a o elimina și folosiți fluxul propriu de recuperare al serviciului în loc să ștergeți fișiere sub un demon care rulează.

Cum arată acceptarea

Patru verificări acoperă proiectul: identitatea prevăzută a controlerului se conectează, un proces fără acea identitate este respins, demonul supraviețuiește unui controler care se deconectează fără avertisment, iar tunelul transportă în continuare trafic printr-o repornire controlată. O conexiune de administrare reușită dovedește doar planul de control. Nu spune nimic despre funcționarea traficului aplicațiilor private, așa că testați-l separat. Notați cele patru rezultate acolo unde următorul operator le poate găsi.

Documentația interfeței de administrare descrie modelul cu un singur client și natura privilegiată a protocolului, iar aceasta este partea care merită citită înainte de a îndrepta un tablou de bord spre el.