OpenVPN Access Server: reiniciar o daemon ou aplicar o axuste

Péganse dous comandos para o que parece a mesma tarefa en OpenVPN Access Server, e fan cousas distintas. systemctl restart openvpnas detén e arranca todo o produto. sacli start levanta os servizos internos que len a configuración que acaba de cambiar. Elixir entre eles non é cuestión de gusto: depende do que diga a documentación do propio axuste, de se a súa sesión pasa polo servidor que vai reiniciar e de se sequera está a mirar o produto correcto.

Dúas capas, un daemon

Access Server execútase como unha soa unidade de systemd, openvpnas, e ese daemon supervisa os servizos internos detrás da interface web e os oíntes de VPN. sacli é a interface de liña de ordes cara á mesma instalación, en /usr/local/openvpn_as/scripts/sacli, e pode arrancar, deter e consultar eses compoñentes internos sen substituír a unidade.

Por iso existen os dous comandos. Un reinicio do daemon volve executalo todo, incluído o proceso que remata os túneles dos clientes. sacli start pide ao daemon que xa está en marcha que levante os seus compoñentes para que lean a nova configuración, e iso é o que realmente requiren a maioría dos cambios de propiedades.

Condición un: que di a documentación do axuste

Lea a páxina do axuste que cambiou, non a dun axuste que cambiou o mes pasado. Unha propiedade escrita mediante ConfigPut adoita ir seguida de sacli start, e ese par é o paso de aplicación documentado. Un cambio no comportamento a nivel de oínte, ou calquera cousa que a páxina describa como necesitada de reinicio do servizo, é a clase na que o reinicio da unidade é correcto.

Os dous comandos non son intercambiables, así que o modo de fallo ao adiviñar é asimétrico. Usar sacli start cando facía falta un reinicio completo deixa un proceso vello servindo a configuración anterior, o que parece que o axuste se ignorou. Facer un reinicio completo cando abondaba sacli start bota a todos os clientes conectados sen motivo.

Condición dous: a súa propia sesión está dentro do túnel

Se administra Access Server a través da VPN que proporciona, o reinicio elimina a conexión que leva a súa shell. O comando pode completarse despois de que morra a súa sesión, e entón dubida de se funcionou. sacli start tamén pode interromper brevemente unha sesión polo mesmo motivo cando o compoñente que se reinicia xestiona o seu tráfico.

Manteña aberta unha vía fóra de banda antes de calquera dos dous comandos: unha consola do provedor, unha consola do hipervisor ou unha sesión serie. Esta condición decide cando executa o comando, non cal executa, e é a que converte un cambio de dous minutos nun informe de caída.

Condición tres: é este o produto que cre

Access Server non é Community OpenVPN. Unha instalación community executa unidades como openvpn@server ou openvpn-client@profile, coa configuración en /etc/openvpn, e alí sacli non existe. Reiniciar todas as unidades con openvpn no nome nun host compartido é a forma en que túneles non relacionados caen xuntos.

Identifique antes de tocar nada: systemctl status openvpnas --no-pager responde se Access Server é o que se está executando, sacli status lista os seus compoñentes internos e systemctl list-units --type=service lista as unidades cuxos nomes conteñen openvpn. Se o último comando mostra unidades con nomes de perfil, está no produto community e o resto disto non se lle aplica.

Aplíqueo e logo verifique máis alá de active

Unha unidade que informa active ten un proceso en marcha, o que non é o mesmo que unha ruta de autenticación que funcione. Tras o paso de aplicación, revise sacli status para os compoñentes que esperaba reiniciar, confirme que o valor se gardou con sacli ConfigQuery e logo execute un inicio de sesión de cliente limitado cunha conta de proba.

Remate con algo a nivel de aplicación: chegue a un recurso privado polo túnel, non só un ping ao enderezo público do servidor. Un handshake que ten éxito mentres a ruta empurrada ou o axuste de DNS son incorrectos pasará todas as comprobacións do servizo e aínda así fallará á persoa que reportou o problema.

o tutorial do provedor sobre xestión de servizos é a referencia de que operacións pertencen a sacli, e paga a pena abrila antes de decidir que un reinicio é a opción segura.

A decisión nunha pasada

Percorra estas catro liñas e detéñase na primeira que encaixe:

• A páxina do axuste nomea sacli start, ou acaba de executar ConfigPut: use sacli start.
• A páxina esixe un reinicio, ou o cambio toca oíntes e non propiedades: use systemctl restart openvpnas.
• A súa shell chega por este servidor: prepare primeiro o acceso á consola e logo execute o comando que elixisen as dúas liñas anteriores.
• Verificación: sacli status, ConfigQuery para o valor, un inicio de sesión, un recurso privado. O estado do servizo por si só non é a meta.

Dúas desas liñas son comprobacións e dúas son accións, e ese é o sentido da orde. Se non pode responder a pregunta sobre o produto, detéñase: o comando que ía executar pertence a outra instalación, e o túnel que bote abaixo non será o que pretendía.