Berre éin managementklient: derfor kastar overvakinga ut grensesnittet
Management-socketen tek éi tilkopling om gongen. Ein andre abonnent klarar ikkje å kopla seg på eller stel kontrollen frå komponenten som eig promptane.
Eit skrivebordsgrensesnitt held managementtilkoplinga, så eit overvakingsskript som prøver å opne si eiga, les ingenting eller, verre, sluttar grensesnittet å svare på promptar. Den vanlege konklusjonen er at daemonen er ustabil. I fellesskapsdaemonen er avgrensinga tilsikta: kontrollgrensesnittet tener éin tilkopla managementklient om gongen, og det talet har ingenting å gjere med kor mange brukarar VPN kan bera.
Éin socket, éin innehavar
Managementkanalen godtek éin tilkopla klient. Når ein andre kjem medan den første er aktiv, ventar han eller blir avvist, og det finst ingen parallell abonnentmodus gøymd bak eit val. Å kopla frå den noverande innehavaren lèt daemonen godta den neste, noko som er ei overlevering og ikkje ein andre kanal.
Det gjer kvart ekstra verktøy til ein konkurrent. Eig grensesnittet tilkoplinga, klarar eit pollande skript ikkje å kopla seg på, eller først etter at grensesnittet har gjeve opp, og sekvensen blir gjenteken ved neste gjenoppkopling. Koplar skriptet seg på først, mistar grensesnittet kontrollvegen sin, og promptane sluttar å verke. Ingen av verktøya rapporterer konflikten, fordi kvart av dei berre ser sin eigen mislukka kommando.
| 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 |
Avgjer kva komponent som eig kontrollen
Vel éin innehavar for den interaktive kanalen og lat han vere det einaste som koplar til. Eit grensesnitt som styrer tilkoplinga, eit skript som svarer på autentiseringspromptar og ein kontrollør som avsluttar økter tel alle som innehavarar, og berre éin kan ha rolla.
Når eit grensesnitt eig tilkoplinga, bruk integrasjonen grensesnittet byr på i staden for å kjempe mot det. Å konkurrere med innehavaren om socketen gjev sporadiske feil som verkar tilfeldige for brukarane, og den som feilsøkjer ser oftast berre andre halvdel av kappløpet. Noter kva prosess som koplar til først etter ein omstart, fordi den rekkjefølgja avgjer kvar gong kven som vinn. Ei overvaking som startar før grensesnittet held kanalen til grensesnittet gjev opp.
Bruk statusaugeblinksbilete for innsamlarane
Dei fleste overvakingsbehova treng ei liste, ikkje ein samtale. Ei periodisk statusfil svarer på det utan å røre kontrollkanalen, og ho held fram med å verke medan grensesnittet blir verande tilkopla.
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixIntervallet er ferskleiksbudsjettet, så set det etter kva dashbordet faktisk treng og ikkje etter den minste verdien som verkar trygg. Eit augeblinksbilete som blir skrive kvart par sekund er billeg; eit skript som gjenoppkoplar til kontrollsocketen kvart par sekund er det ikkje, fordi kvar gjenoppkopling konkurrerer med innehavaren.
Eit augeblinksbilete er ikkje ein historikk og ikkje ein hendingsstraum. Tilkoplingar som kjem og går innanfor eitt intervall viser seg aldri, så eit revisjonskrav kan ikkje oppfyllast ved å polle ei fil som overskriv seg sjølv. Viss du må vite om ein brukar i det heile var tilkopla, er augeblinksbiletet feil instrument.
Spreiing er ein design, ikkje ein modus
Viss fleire forbrukarar verkeleg treng levande managementdata, set éin betrudd komponent framfor socketen og lat han publisere nøye utvalde observasjonar til resten. Den komponenten eig gjenoppkoplinga, autentiseringspromptane og avgjerda om kva som er trygt å eksponere.
Bygg han medvite: definer kva spørjingar som er tillatne, logg kven som spurde, og unngå å gjere spreiingslaget til eit fjernkontrollpanel ved eit uhell. Daemonen har ingen fleirklientmodus å slå på, og inga konfigurasjonslinje lagar ein. Handsama innehavaren som ein del av sikkerheitsgrensa, fordi han held eit grensesnitt som kan kopla frå folk. Ein omstart bør vere ei rutinehandling med ein dokumentert gjenopprettingsveg.
Handsama socketen som privilegium, ikkje som statistikk
Managementgrensesnittet kan kopla frå brukarar, endre tilstand og lese hendingar som namngjev personar. Passordet autentiserer klienten og krypterer ikkje transporten, så ein nettverkslyttar eksponerer samtalen for alle som kan observere han.
Føretrekk ein lokal socket eller ein strengt avgrensa lyttar, og kontroller kva prosess innsamlaren din faktisk vender seg til, sidan serverprodukt leverer eigne management-API-ar som oppfører seg annleis. Ein innsamlar retta mot feil daemon gjev trygge, gale konklusjonar. Stadfest stien og den eigde prosessen før du feilsøkjer ei spørjing som ikkje returnerer noko.