Kun én managementklient: derfor sparker din monitor grænsefladen ud

En desktop-grænseflade holder managementforbindelsen, så et overvågningsscript, der prøver at åbne sin egen, læser intet eller, værre, holder grænsefladen op med at svare på prompter. Den sædvanlige konklusion er, at daemonen er ustabil. I community-daemonen er begrænsningen bevidst: kontrolgrænsefladen betjener én tilsluttet managementklient ad gangen, og det antal har intet at gøre med, hvor mange brugere VPN kan bære.

Én socket, én indehaver

Managementkanalen accepterer én tilsluttet klient. Når en anden ankommer, mens den første er aktiv, venter den eller afvises, og der findes ingen parallel abonnenttilstand skjult bag en indstilling. Afbryder man den nuværende indehaver, kan daemonen acceptere den næste, hvilket er en overdragelse og ikke en anden kanal.

Det gør ethvert ekstra værktøj til en konkurrent. Ejer grænsefladen forbindelsen, kan et pollende script ikke koble sig på eller først efter, at grænsefladen har givet op, og sekvensen gentages ved næste genopkobling. Kobler scriptet sig på først, mister grænsefladen sin kontrolvej, og dens prompter holder op med at virke. Ingen af værktøjerne rapporterer konflikten, fordi hvert af dem kun ser sin egen mislykkede kommando.

Beslut, hvilken komponent der ejer kontrollen

Vælg én indehaver til den interaktive kanal, og lad den være det eneste, der kobler sig på. En grænseflade, der styrer forbindelsen, et script, der besvarer godkendelsesprompter, og en controller, der afslutter sessioner, tæller alle som indehavere, og kun én kan have rollen.

Når en grænseflade ejer forbindelsen, brug den integration, grænsefladen tilbyder, i stedet for at kæmpe imod den. At konkurrere med indehaveren om socket'en giver sporadiske fejl, der virker tilfældige for brugerne, og den, der fejlretter, ser oftest kun anden halvdel af kapløbet. Noter, hvilken proces der kobler sig på først efter en genstart, for den rækkefølge afgør hver gang, hvem der vinder. En monitor, der starter før grænsefladen, beholder kanalen, indtil grænsefladen giver op.

Brug statusøjebliksbilleder til indsamlerne

De fleste overvågningsbehov kræver en liste, ikke en samtale. En periodisk statusfil svarer på det uden at røre kontrolkanalen, og den bliver ved med at virke, mens grænsefladen forbliver tilsluttet.

status /run/openvpn/server.status 10
management /run/openvpn/server.sock unix

Intervallet er friskhedsbudgettet, så sæt det efter, hvad instrumentpanelet faktisk har brug for, og ikke efter den mindste værdi, der virker sikker. Et øjebliksbillede, der skrives hvert par sekunder, er billigt; et script, der genopkobler til kontrolsocket'en hvert par sekunder, er det ikke, fordi hver genopkobling konkurrerer med indehaveren.

Et øjebliksbillede er ikke en historik og ikke en hændelsesstrøm. Forbindelser, der kommer og går inden for ét interval, optræder aldrig, så et revisionskrav kan ikke opfyldes ved at polle en fil, der overskriver sig selv. Hvis du skal vide, om en bruger overhovedet var tilsluttet, er øjebliksbilledet det forkerte instrument.

Udbredelse er et design, ikke en tilstand

Hvis flere forbrugere virkelig har brug for live managementdata, sæt én betroet komponent foran socket'en, og lad den offentliggøre nøje udvalgte observationer til resten. Den komponent ejer genopkoblingen, godkendelsesprompterne og beslutningen om, hvad der er sikkert at eksponere.

Byg den bevidst: definer, hvilke forespørgsler der er tilladte, log hvem der spurgte, og undgå at gøre udbredelseslaget til et fjernbetjeningspanel ved et uheld. Daemonen har ingen flerklienttilstand at slå til, og ingen konfigurationslinje skaber en. Behandl indehaveren som en del af sikkerhedsgrænsen, fordi den holder en grænseflade, der kan afbryde folk. En genstart bør være en rutinehandling med en dokumenteret genopretningsvej.

Behandl socket'en som privilegium, ikke som statistik

Managementgrænsefladen kan afbryde brugere, ændre tilstand og læse hændelser, der navngiver personer. Dens adgangskode godkender klienten og krypterer ikke transporten, så en netværkslytter blotlægger samtalen for enhver, der kan observere den.

Foretræk en lokal socket eller en strengt begrænset lytter, og kontroller, hvilken proces din indsamler faktisk henvender sig til, da serverprodukter leverer deres egne management-API'er, som opfører sig anderledes. En indsamler rettet mod den forkerte daemon giver sikre, forkerte konklusioner. Bekræft stien og den ejende proces, før du fejlretter en forespørgsel, der intet returnerer.