OpenVPN-beheersocket: een regelkanaal, geen metrieken

Vraag de beheerinterface één keer om een status en hij begint op een statuspoort te lijken. Dat is hij niet. Zodra een client is toegelaten, kan hij de regelopdrachten van het protocol uitvoeren, en het account dat die client draait erft alles wat die opdrachten met de daemon kunnen doen. Het als een alleen-lezen feed behandelen is de fout die een monitoringintegratie in een niet-geauthenticeerde console verandert.

De overtuiging, en wat zij kost

De overtuiging is dat de beheerlistener gelijkstaat aan een metriek-eindpunt: sluit een collector aan, lees de tellers, ga verder. Wat er werkelijk gebeurt, is dat de collector een sessie met regelvermogen opent, en elke andere aanname die je over de uitrol deed hangt nu af van het goede gedrag van die collector.

Niets in de interface adverteert een alleen-lezen modus. Er is geen observatorrol om te kiezen, en een gebruikersnaam in de configuratie maakt er geen.

Wat een toegelaten client werkelijk houdt

De community-daemon accepteert slechts één actieve beheerclient tegelijk. Die ene plek betekent dat een GUI, een script en een monitoringagent niet allemaal kunnen verbinden; de tweede wacht of faalt terwijl de eerste de sessie houdt. Als je ontwerp gelijktijdige lezers veronderstelt, is het al fout.

Waar een periodieke momentopname volstaat, geeft de uitvoer van het statusbestand dezelfde getallen zonder een live sessie. Dat bestand met tussenpozen schrijven en het met gewone bestandsrechten lezen houdt de collector volledig buiten het regelvlak, en dat is de opzet die de meeste monitoring echt nodig heeft.

Een eigen socket, geen open socket

Een Unix-domeinsocket houdt het regelpad buiten het netwerk, wat het wisselende tunneladres uit het probleem haalt. Het haalt de rechtenvraag er niet uit. De bovenliggende map moet schrijfbaar zijn voor het serviceaccount en bereikbaar voor het account van de controller, en dat zijn twee aparte rechten:

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

Het wachtwoordbestand draagt het beheergeheim op de eerste regel. Bescherm dat bestand als elke andere inloggegevens en houd de inhoud buiten logboeken en supporttickets. De gebruiker- en groepsbeperkingen zijn peer-controles op de Unix-socket, geen bestandssysteemrechten, dus het beoogde proces heeft zowel de bestandstoegang als de bijbehorende identiteit nodig.

De socket wereldwijd toegankelijk maken om een rechtenfout op te lossen is de enige oplossing die je moet vermijden. Het verandert een lokaal regelkanaal in iets wat elk proces op de host kan besturen.

Publiceren via TCP is niet hetzelfde ontwerp

De listener naar een TCP-poort verplaatsen maakt hem niet veiliger of handiger. Het beheerwachtwoord wordt in platte tekst verzonden, dus een TCP-listener stelt zowel de inloggegevens als de sessie bloot aan iedereen die het pad kan observeren. Om hem vanaf een andere host te bereiken is een geautoriseerd beheerkanaal nodig, of een kleine lokale agent die alleen de observaties blootlegt die je nodig hebt.

Een wachtwoord over een platte-teksttransport is authenticatie zonder vertrouwelijkheid, en die combinatie is erger dan hij lijkt omdat hij beschermd aanvoelt.

Opstartafhankelijkheden die je niet vroeg

Verschillende beheeropties veranderen de levenscyclus van de daemon. Het opstarten tegenhouden tot een controller verbindt, of beëindigen wanneer de controller verdwijnt, maakt van een optionele observator een harde afhankelijkheid. Een monitoringagent die crasht zou dan de tunnel mee naar beneden nemen.

Bekijk die opties voordat je iets buiten de socket zelf inschakelt. Optionele observatie moet optioneel blijven, en een herstartbeleid mag niet gekoppeld worden aan een collector die voor grafieken is toegevoegd.

Een socketbestand dat na een mislukt proces achterblijft is geen bewijs dat er een listener bestaat. Stel vast welke instantie het pad bezit voordat je het verwijdert, en gebruik de eigen herstelworkflow van de dienst in plaats van bestanden onder een draaiende daemon te verwijderen.

Hoe acceptatie eruitziet

Vier controles dekken het ontwerp: de beoogde controlleridentiteit verbindt, een proces zonder die identiteit wordt geweigerd, de daemon overleeft een controller die zonder waarschuwing loskoppelt, en de tunnel vervoert nog steeds verkeer door een gecontroleerde herstart. Een geslaagde beheerverbinding bewijst alleen het regelvlak. Hij zegt niets over of verkeer van privétoepassingen werkt, dus test dat apart. Schrijf de vier resultaten op waar de volgende beheerder ze kan vinden.

De documentatie van de beheerinterface beschrijft het enkelclientmodel en het geprivilegieerde karakter van het protocol, en dat is het deel dat de moeite waard is om te lezen voordat je er een dashboard op richt.