OpenVPN Access Server: riavviare il demone o applicare l’impostazione

Due comandi vengono incollati per quello che sembra lo stesso lavoro su OpenVPN Access Server, e fanno cose diverse. systemctl restart openvpnas arresta e avvia l’intero prodotto. sacli start avvia i servizi interni che leggono la configurazione appena modificata. Scegliere tra i due non è questione di gusto: dipende da ciò che dice la documentazione dell’impostazione stessa, se la vostra sessione passa attraverso il server che state per riavviare e se state guardando il prodotto giusto.

Due livelli, un demone

Access Server viene eseguito come una singola unità systemd, openvpnas, e quel demone sovrintende ai servizi interni dietro l’interfaccia web e agli ascoltatori VPN. sacli è l’interfaccia a riga di comando verso la stessa installazione, in /usr/local/openvpn_as/scripts/sacli, e può avviare, arrestare e interrogare quei componenti interni senza sostituire l’unità.

Ecco perché esistono entrambi i comandi. Un riavvio del demone riesegue tutto, compreso il processo che termina i tunnel dei client. sacli start chiede al demone già in esecuzione di alzare i suoi componenti perché leggano la nuova configurazione, ed è ciò che la maggior parte delle modifiche di proprietà richiede davvero.

Prima condizione: cosa dice la documentazione dell’impostazione

Leggete la pagina dell’impostazione che avete cambiato, non quella di un’impostazione cambiata il mese scorso. Una proprietà scritta tramite ConfigPut è di solito seguita da sacli start, e quella coppia è il passo di applicazione documentato. Una modifica al comportamento a livello di ascoltatore, o qualunque cosa la pagina descriva come bisognosa di un riavvio del servizio, è la classe in cui il riavvio dell’unità è corretto.

I due comandi non sono intercambiabili, quindi il modo di sbagliare quando si indovina è asimmetrico. Usare sacli start quando serviva un riavvio completo lascia un vecchio processo che serve ancora la configurazione precedente, e sembra che l’impostazione sia stata ignorata. Un riavvio completo quando sarebbe bastato sacli start butta fuori ogni client connesso senza motivo.

Seconda condizione: la vostra sessione è dentro il tunnel

Se amministrate Access Server attraverso la VPN che fornisce, il riavvio rimuove la connessione che porta la vostra shell. Il comando può completarsi dopo che la sessione è morta, e allora dovete indovinare se ha funzionato. sacli start può anche interrompere brevemente una sessione per lo stesso motivo quando il componente riavviato gestisce il vostro traffico.

Tenete aperto un percorso fuori banda prima di entrambi i comandi: una console del provider, una console dell’hypervisor o una sessione seriale. Questa condizione decide quando eseguite il comando, non quale, ed è quella che trasforma una modifica di due minuti in un rapporto di interruzione.

Terza condizione: è questo il prodotto che credete

Access Server non è Community OpenVPN. Un’installazione community esegue unità come openvpn@server o openvpn-client@profile, con la configurazione in /etc/openvpn, e lì sacli non esiste. Riavviare ogni unità con openvpn nel nome su un host condiviso è il modo in cui tunnel non correlati cadono insieme.

Identificate prima di toccare qualcosa: systemctl status openvpnas --no-pager risponde se Access Server è ciò che è in esecuzione, sacli status elenca i suoi componenti interni e systemctl list-units --type=service elenca le unità i cui nomi contengono openvpn. Se l’ultimo comando mostra unità con nomi di profilo, siete sul prodotto community e il resto di questo non vi riguarda.

Applicate, poi verificate oltre active

Un’unità che riporta active ha un processo in esecuzione, che non è lo stesso di un percorso di autenticazione funzionante. Dopo il passo di applicazione, controllate sacli status per i componenti che vi aspettavate venissero riavviati, confermate che il valore sia stato salvato con sacli ConfigQuery e poi eseguite un accesso client limitato con un account di prova.

Chiudete con qualcosa a livello applicativo: raggiungete una risorsa privata attraverso il tunnel, non solo un ping all’indirizzo pubblico del server. Un handshake che riesce mentre la rotta inviata o l’impostazione DNS sono errate supererà ogni controllo del servizio e comunque deluderà la persona che ha segnalato il problema.

il tutorial del provider sulla gestione dei servizi è il riferimento su quali operazioni appartengono a sacli, e vale la pena aprirlo prima di decidere che un riavvio sia l’opzione sicura.

La decisione in una passata

Percorrete queste quattro righe e fermatevi alla prima che corrisponde:

• La pagina dell’impostazione nomina sacli start, o avete appena eseguito ConfigPut: usate sacli start.
• La pagina richiede un riavvio, o la modifica tocca gli ascoltatori e non le proprietà: usate systemctl restart openvpnas.
• La vostra shell arriva attraverso questo server: predisponete prima l’accesso alla console, poi eseguite il comando scelto dalle due righe sopra.
• Verifica: sacli status, ConfigQuery per il valore, un accesso, una risorsa privata. Il solo stato del servizio non è il traguardo.

Due di quelle righe sono controlli e due sono azioni, ed è questo il senso dell’ordine. Se non riuscite a rispondere alla domanda sul prodotto, fermatevi: il comando che stavate per eseguire appartiene a un’altra installazione, e il tunnel che abbatterete non sarà quello che intendevate.