OpenVPN Access Server: de daemon herstarten of de instelling toepassen

Er worden twee opdrachten geplakt voor wat op OpenVPN Access Server dezelfde taak lijkt, en ze doen verschillende dingen. systemctl restart openvpnas stopt en start het hele product. sacli start brengt de interne diensten omhoog die de configuratie lezen die je net hebt gewijzigd. Kiezen tussen beide is geen kwestie van smaak: het hangt af van wat de documentatie van de instelling zelf zegt, of je sessie via de server loopt die je gaat herstarten, en of je überhaupt naar het juiste product kijkt.

Twee lagen, één daemon

Access Server draait als één systemd-eenheid, openvpnas, en die daemon houdt toezicht op de interne diensten achter de webinterface en de VPN-luisteraars. sacli is de opdrachtregelinterface naar dezelfde installatie, op /usr/local/openvpn_as/scripts/sacli, en kan die interne componenten starten, stoppen en bevragen zonder de eenheid te vervangen.

Daarom bestaan beide opdrachten. Een herstart van de daemon voert alles opnieuw uit, inclusief het proces dat clienttunnels beëindigt. sacli start vraagt de al draaiende daemon zijn componenten omhoog te brengen zodat ze de nieuwe configuratie lezen, en dat is wat de meeste eigenschapswijzigingen echt vereisen.

Eerste voorwaarde: wat de documentatie van de instelling zegt

Lees de pagina van de instelling die je hebt gewijzigd, niet van een instelling van vorige maand. Na een eigenschap die via ConfigPut is geschreven volgt meestal sacli start, en dat paar is de gedocumenteerde toepassingsstap. Een wijziging in gedrag op luisteraarniveau, of alles wat de pagina beschrijft als een herstart van de dienst vereisend, is de klasse waarin de herstart van de eenheid juist is.

De twee opdrachten zijn niet uitwisselbaar, dus de foutmodus bij gokken is asymmetrisch. sacli start gebruiken terwijl een volledige herstart nodig was, laat een oud proces de vorige configuratie nog bedienen, wat lijkt alsof de instelling is genegeerd. Een volledige herstart terwijl sacli start genoeg was, gooit elke verbonden client zonder reden eruit.

Tweede voorwaarde: zit je eigen sessie in de tunnel

Als je Access Server beheert via de VPN die het levert, verwijdert de herstart de verbinding die je shell draagt. De opdracht kan pas klaar zijn nadat je sessie sterft, zodat je moet raden of het werkte. sacli start kan een sessie ook kort onderbreken om dezelfde reden wanneer de herstartte component je verkeer afhandelt.

Houd een pad buiten de band open vóór beide opdrachten: een providerconsole, een hypervisorconsole of een seriële sessie. Deze voorwaarde bepaalt wanneer je de opdracht uitvoert, niet welke, en zij is het die een wijziging van twee minuten in een storingsrapport verandert.

Derde voorwaarde: is dit het product dat je denkt

Access Server is niet Community OpenVPN. Een community-installatie draait eenheden zoals openvpn@server of openvpn-client@profile, met de configuratie in /etc/openvpn, en sacli bestaat daar niet. Elke eenheid met openvpn in de naam op een gedeelde host herstarten is hoe ongerelateerde tunnels samen onderuitgaan.

Stel vast voordat je iets aanraakt: systemctl status openvpnas --no-pager antwoordt of Access Server degene is die draait, sacli status somt de interne componenten op, en systemctl list-units --type=service somt eenheden op waarvan de naam openvpn bevat. Als de laatste opdracht eenheden met profielnamen toont, zit je op het communityproduct en de rest hiervan geldt niet voor jou.

Toepassen, en daarna verder kijken dan active

Een eenheid die active meldt heeft een draaiend proces, wat niet hetzelfde is als een werkend authenticatiepad. Controleer na de toepassingsstap sacli status voor de componenten waarvan je verwachtte dat ze herstart werden, bevestig dat de waarde met sacli ConfigQuery is opgeslagen, en voer dan één beperkte clientaanmelding uit met een testaccount.

Sluit af met iets op applicatieniveau: bereik een privébron via de tunnel, niet alleen een ping naar het openbare adres van de server. Een handshake die slaagt terwijl de gepushte route of de DNS-instelling fout is, doorstaat elke dienstcontrole en laat de persoon die het probleem meldde alsnog in de steek.

de dienstbeheertutorial van de provider is de referentie voor welke bewerkingen bij sacli horen, en het loont die te openen voordat je besluit dat een herstart de veilige optie is.

De beslissing in één doorloop

Werk deze vier regels af en stop bij de eerste die past:

• De instellingspagina noemt sacli start, of je hebt net ConfigPut uitgevoerd: gebruik sacli start.
• De pagina vereist een herstart, of de wijziging raakt luisteraars in plaats van eigenschappen: gebruik systemctl restart openvpnas.
• Je shell komt via deze server: regel eerst consoletoegang en voer dan de opdracht uit die de twee regels hierboven kozen.
• Controle: sacli status, ConfigQuery voor de waarde, één aanmelding, één privébron. Alleen de dienststatus is niet de finishlijn.

Twee van die regels zijn controles en twee zijn handelingen, en dat is het punt van de volgorde. Kun je de productvraag niet beantwoorden, stop dan: de opdracht die je wilde uitvoeren hoort bij een andere installatie, en de tunnel die je neerhaalt is niet degene die je bedoelde.