Un singur client de administrare: de ce monitorul dumneavoastră scoate interfața grafică
Socketul de administrare acceptă o singură conexiune odată. Un al doilea abonat fie nu se poate atașa, fie fură controlul de la componenta care deține prompturile.
O interfață grafică de birou ține conexiunea de administrare, așa că un script de monitorizare care încearcă să deschidă una proprie nu citește nimic sau, mai rău, interfața nu mai răspunde la prompturi. Concluzia obișnuită este că daemonul este instabil. În daemonul comunității limitarea este intenționată: interfața de control deservește un singur client de administrare conectat odată, iar acel număr nu are nimic de-a face cu câți utilizatori poate duce VPN-ul.
Un socket, un singur deținător
Canalul de administrare acceptă un singur client conectat. Când sosește un al doilea în timp ce primul este activ, acesta așteaptă sau este refuzat, și nu există niciun mod abonat paralel ascuns în spatele unei opțiuni. Deconectarea deținătorului actual permite daemonului să accepte următorul, ceea ce este o predare, nu un al doilea canal.
Asta face din fiecare instrument suplimentar un concurent. Dacă interfața deține conexiunea, un script de interogare fie nu se atașează, fie reușește doar după ce interfața a renunțat, iar secvența se repetă la următoarea reconectare. Dacă scriptul se atașează primul, interfața își pierde calea de control și prompturile ei nu mai funcționează. Niciunul dintre instrumente nu raportează conflictul, pentru că fiecare vede doar propria comandă eșuată.
| 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 |
Decideți care componentă deține controlul
Alegeți un singur deținător pentru canalul interactiv și lăsați-l să fie singurul care se conectează. O interfață care gestionează conexiunea, un script care răspunde la prompturile de autentificare și un controler care termină sesiuni se numără toate ca deținători, iar doar unul poate avea rolul.
Când o interfață deține conexiunea, folosiți integrarea pe care o oferă, în loc să vă luptați cu ea. Competiția cu deținătorul pentru socket produce defecțiuni intermitente care le par utilizatorilor aleatorii, iar cel care depanează vede de obicei doar a doua jumătate a cursei. Notați care proces se conectează primul după o repornire, pentru că acea ordine decide de fiecare dată cine câștigă. Un monitor care pornește înaintea interfeței va păstra canalul până când interfața renunță.
Folosiți instantanee de stare pentru colectori
Majoritatea monitorizării are nevoie de o listă, nu de o conversație. Un fișier de stare periodic răspunde la asta fără să atingă canalul de control și continuă să funcționeze cât timp interfața rămâne conectată.
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixIntervalul este bugetul de prospețime, așa că setați-l la ce are nevoie cu adevărat panoul și nu la cea mai mică valoare care pare sigură. Un instantaneu scris la fiecare câteva secunde este ieftin; un script care se reconectează la socketul de control la fiecare câteva secunde nu este, pentru că fiecare reconectare concurează cu deținătorul.
Un instantaneu nu este un istoric și nu este un flux de evenimente. Conexiunile care sosesc și pleacă în interiorul unui interval nu apar niciodată, așa că o cerință de audit nu poate fi satisfăcută interogând un fișier care se suprascrie. Dacă trebuie să știți că un utilizator s-a conectat măcar o dată, instantaneul este instrumentul greșit.
Distribuirea este un proiect, nu un mod
Dacă mai mulți consumatori au într-adevăr nevoie de date de administrare în timp real, puneți o singură componentă de încredere în fața socketului și lăsați-o să publice observații strict alese către ceilalți. Acea componentă deține reconectarea, prompturile de autentificare și decizia despre ce este sigur de expus.
Construiți-o deliberat: definiți ce interogări sunt permise, înregistrați cine a întrebat și evitați să transformați din greșeală stratul de distribuire într-un panou de control de la distanță. Daemonul nu are niciun mod cu mai mulți clienți de activat și nicio linie de configurare nu creează unul. Tratați deținătorul ca parte a graniței de securitate, pentru că ține o interfață care poate deconecta oameni. Repornirea lui ar trebui să fie o operațiune de rutină cu o cale de recuperare documentată.
Tratați socketul ca privilegiu, nu ca metrici
Interfața de administrare poate deconecta utilizatori, poate schimba starea și citi evenimente care numesc persoane. Parola ei autentifică clientul și nu criptează transportul, așa că un ascultător de rețea expune conversația oricui o poate observa.
Preferați un socket local sau un ascultător strict restricționat și verificați cărui proces i se adresează de fapt colectorul dumneavoastră, deoarece produsele de server livrează propriile API-uri de administrare care se comportă diferit. Un colector îndreptat spre daemonul greșit produce concluzii sigure și greșite. Confirmați calea și procesul proprietar înainte de a depana o interogare care nu returnează nimic.