OpenVPN-beheersokkel: ’n beheerkanaal, nie statistieke nie

Vra die bestuurskoppelvlak een keer vir ’n status, en dit begin soos ’n statuspoort lyk. Dit is nie een nie. Sodra ’n kliënt toegelaat word, kan dit die protokol se beheeropdragte uitreik, en die rekening wat daardie kliënt laat loop, erf alles wat daardie opdragte aan die daemon kan doen. Om dit as ’n leesalleen-voerstroom te behandel, is die fout wat ’n moniteringintegrasie in ’n ongemagtigde konsole verander.

Die oortuiging, en wat dit kos

Die oortuiging is dat die bestuursluisteraar gelykstaande is aan ’n metriek-eindpunt: koppel ’n versamelaar, lees die tellers, gaan aan. Wat eintlik gebeur, is dat die versamelaar ’n sessie met beheervermoëns oopmaak, en elke ander aanname wat jy oor die ontplooiing gemaak het, hang nou daarvan af dat daardie versamelaar hom goed gedra.

Niks in die koppelvlak adverteer ’n leesalleen-modus nie. Daar is geen waarnemerrol om te kies nie, en ’n gebruikersnaam in die konfigurasie skep nie een nie.

Wat ’n toegelate kliënt werklik in die hande het

Die gemeenskaps-daemon aanvaar een aktiewe bestuurskliënt op ’n slag. Daardie enkele slot beteken dat ’n GUI, ’n skrip en ’n moniteringsagent nie almal kan koppel nie; die tweede wag of misluk terwyl die eerste die sessie hou. As jou ontwerp gelyktydige lesers veronderstel, is dit reeds verkeerd.

Waar ’n periodieke momentopname genoeg is, gee die statuslêer-uitset vir jou dieselfde syfers sonder ’n lewendige sessie. Om daardie lêer met tussenposes te skryf en dit met gewone lêertoestemmings te lees, hou die versamelaar heeltemal buite die beheervlak, en dit is die reëling wat die meeste monitering eintlik nodig het.

’n Beheerde sokkel, nie ’n oop een nie

’n Unix-domeinsokkel hou die beheerpad van die netwerk af, wat die veranderende tonneladres uit die probleem verwyder. Dit verwyder nie die toestemmingsvraag nie. Die ouerdirektorie moet deur die diensrekening beskryfbaar wees en deur die kontroleerder se rekening bereikbaar wees, en dit is twee afsonderlike toekennings:

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

Die wagwoordlêer dra die bestuursgeheim as sy eerste reël. Beskerm daardie lêer soos enige ander geloofsbewys, en hou die inhoud daarvan uit logs en ondersteuningskaartjies. Die gebruiker- en groepbeperkings is portuurkontroles op die Unix-sokkel, nie lêerstelseltoestemmings nie, so die bedoelde proses het beide die lêertoegang en die ooreenstemmende identiteit nodig.

Om die sokkel wêreldwyd toeganklik te maak om ’n toestemmingsfout op te los, is die een regstelling wat jy moet vermy. Dit verander ’n plaaslike beheerkanaal in iets wat enige proses op die gasheer kan bestuur.

Om dit oor TCP te publiseer, is nie dieselfde ontwerp nie

Om die luisteraar na ’n TCP-poort te skuif, maak dit nie veiliger of geriefliker nie. Die bestuurswagwoord word in die oopte gestuur, so ’n TCP-luisteraar stel beide die geloofsbewys en die sessie bloot aan enigiemand wat die pad kan waarneem. Om dit vanaf ’n ander gasheer te bereik, vereis ’n gemagtigde administrasiekanaal, of ’n klein plaaslike agent wat net die waarnemings blootstel wat jy nodig het.

’n Wagwoord oor ’n gewone-teks vervoer is verifikasie sonder vertroulikheid, en daardie kombinasie is erger as wat dit lyk omdat dit beskermd voel.

Beginafhanklikhede wat jy nie gevra het nie

Verskeie bestuursopsies verander die daemon se lewensiklus. Om die opstart te hou totdat ’n kontroleerder koppel, of om te beëindig wanneer die kontroleerder verdwyn, verander ’n opsionele waarnemer in ’n harde afhanklikheid. ’n Moniteringsagent wat ineenstort, sou dan die tonnel saam met hom aftrek.

Hersien daardie opsies voordat jy iets verder as die sokkel self aktiveer. Opsionele waarneming moet opsioneel bly, en ’n herbeginbeleid moet nie gekoppel wees aan ’n versamelaar wat vir grafieke bygevoeg is nie.

’n Sokellêer wat ná ’n mislukte proses agtergelaat word, is nie bewys dat ’n luisteraar bestaan nie. Identifiseer watter instansie die pad besit voordat jy dit verwyder, en gebruik die diens se eie herstelwerkvloei eerder as om lêers onder ’n lopende daemon te verwyder.

Hoe aanvaarding lyk

Vier kontroles dek die ontwerp: die beoogde kontroleerder-identiteit koppel, ’n proses sonder daardie identiteit word verwerp, die daemon oorleef ’n kontroleerder wat sonder waarskuwing ontkoppel, en die tonnel dra steeds verkeer deur ’n beheerde herbegin. ’n Suksesvolle bestuursverbinding bewys net die beheervlak. Dit sê niks oor of private toepassingsverkeer werk nie, so toets dit afsonderlik. Skryf die vier resultate neer waar die volgende operateur dit kan vind.

Die dokumentasie vir die bestuurskoppelvlak beskryf die enkelkliëntmodel en die bevoorregte aard van die protokol, en dit is die deel wat die moeite werd is om te lees voordat jy ’n paneelbord daarop rig.