OpenVPN Access Server: reinicieu el dimoni o apliqueu la configuració

S’enganxen dues ordres per al que sembla la mateixa feina a OpenVPN Access Server, i fan coses diferents. systemctl restart openvpnas atura i arrenca tot el producte. sacli start aixeca els serveis interns que llegeixen la configuració que acabeu de canviar. Triar entre elles no és una qüestió de gust: depèn del que digui la documentació de la configuració mateixa, de si la vostra sessió passa pel servidor que esteu a punt de reiniciar i de si esteu mirant el producte correcte.

Dues capes, un dimoni

Access Server funciona com una sola unitat systemd, openvpnas, i aquest dimoni supervisa els serveis interns darrere de la interfície web i els oients de VPN. sacli és la interfície de línia d’ordres cap a la mateixa instal·lació, a /usr/local/openvpn_as/scripts/sacli, i pot arrencar, aturar i consultar aquests components interns sense substituir la unitat.

Per això existeixen les dues ordres. Un reinici del dimoni torna a executar-ho tot, inclòs el procés que acaba els túnels dels clients. sacli start demana al dimoni que ja funciona que aixequi els seus components perquè llegeixin la configuració nova, i això és el que requereixen realment la majoria de canvis de propietats.

Condició primera: què diu la documentació de la configuració

Llegiu la pàgina de la configuració que heu canviat, no la d’una que vau canviar el mes passat. Una propietat escrita amb ConfigPut normalment va seguida de sacli start, i aquest parell és el pas d’aplicació documentat. Un canvi en el comportament a nivell d’oient, o qualsevol cosa que la pàgina descrigui com a necessitada de reinici del servei, és la classe en què el reinici de la unitat és correcte.

Les dues ordres no són intercanviables, així que la manera de fallar si endevineu és asimètrica. Fer servir sacli start quan calia un reinici complet deixa un procés vell servint la configuració anterior, cosa que sembla que la configuració s’hagi ignorat. Fer un reinici complet quan sacli start hauria bastat treu tots els clients connectats sense cap motiu.

Condició segona: la vostra sessió és dins del túnel

Si administreu Access Server a través de la VPN que proporciona, el reinici elimina la connexió que porta la vostra shell. L’ordre pot acabar després que la sessió mori, i us queda el dubte de si ha funcionat. sacli start també pot interrompre la sessió un moment pel mateix motiu quan el component que es reinicia gestiona el vostre trànsit.

Tingueu un camí fora de banda obert abans de qualsevol de les dues ordres: una consola del proveïdor, una consola de l’hipervisor o una sessió sèrie. Aquesta condició decideix quan executeu l’ordre, no quina ordre executeu, i és la que converteix un canvi de dos minuts en un informe d’incidència.

Condició tercera: és aquest el producte que us penseu

Access Server no és Community OpenVPN. Una instal·lació community executa unitats com openvpn@server o openvpn-client@profile, amb la configuració a /etc/openvpn, i allà sacli no existeix. Reiniciar totes les unitats amb openvpn al nom en un host compartit és com túnels no relacionats cauen junts.

Identifiqueu abans de tocar res: systemctl status openvpnas --no-pager respon si Access Server és el que s’executa, sacli status llista els seus components interns i systemctl list-units --type=service llista les unitats que contenen openvpn al nom. Si l’última ordre mostra unitats amb nom de perfil, sou al producte community i la resta d’això no us pertoca.

Apliqueu-ho i després verifiqueu més enllà d’active

Una unitat que informa active té un procés en marxa, cosa que no és el mateix que un camí d’autenticació que funcioni. Després del pas d’aplicació, comproveu sacli status per als components que esperàveu reiniciar, confirmeu que el valor s’ha desat amb sacli ConfigQuery i feu un inici de sessió de client limitat amb un compte de prova.

Acabeu amb una cosa a nivell d’aplicació: arribeu a un recurs privat pel túnel, no només un ping a l’adreça pública del servidor. Un handshake que té èxit mentre la ruta empenyida o la configuració de DNS són incorrectes passarà tots els controls del servei i tot i així farà fallar la persona que va reportar el problema.

el tutorial del proveïdor sobre gestió de serveis és la referència de quines operacions pertanyen a sacli, i val la pena obrir-la abans de decidir que un reinici és l’opció segura.

La decisió en una passada

Baixeu per aquestes quatre línies i atureu-vos a la primera que encaixi:

• La pàgina de configuració anomena sacli start, o acabeu d’executar ConfigPut: feu servir sacli start.
• La pàgina requereix un reinici, o el canvi toca oients i no propietats: feu servir systemctl restart openvpnas.
• La vostra shell arriba per aquest servidor: prepareu primer l’accés a la consola i després executeu l’ordre que hagin triat les dues línies de dalt.
• Verificació: sacli status, ConfigQuery per al valor, un inici de sessió, un recurs privat. L’estat del servei tot sol no és la línia d’arribada.

Dues d’aquestes línies són comprovacions i dues són accions, i aquest és el sentit de l’ordre. Si no podeu respondre la pregunta sobre el producte, atureu-vos: l’ordre que anàveu a executar pertany a una altra instal·lació, i el túnel que tireu a terra no serà el que volíeu.