OpenVPN Access Server: repornești demonul sau aplici setarea

Două comenzi sunt lipite pentru ceea ce pare aceeași sarcină pe OpenVPN Access Server, iar ele fac lucruri diferite. systemctl restart openvpnas oprește și pornește întregul produs. sacli start ridică serviciile interne care citesc configurația pe care tocmai ai modificat-o. Alegerea între ele nu ține de gust: depinde de ce spune documentația setării înseși, dacă sesiunea ta trece prin serverul pe care urmează să îl repornești și dacă te uiți măcar la produsul corect.

Două straturi, un demon

Access Server rulează ca o singură unitate systemd, openvpnas, iar acel demon supraveghează serviciile interne din spatele interfeței web și ascultătorii VPN. sacli este interfața de linie de comandă către aceeași instalare, la /usr/local/openvpn_as/scripts/sacli, și poate porni, opri și interoga acele componente interne fără a înlocui unitatea.

De aceea există ambele comenzi. O repornire a demonului execută totul din nou, inclusiv procesul care termină tunelurile clienților. sacli start cere demonului deja pornit să își ridice componentele ca să citească noua configurație, și exact asta cer majoritatea modificărilor de proprietăți.

Prima condiție: ce spune documentația setării

Citește pagina setării pe care ai modificat-o, nu a unei setări modificate luna trecută. După o proprietate scrisă prin ConfigPut urmează de obicei sacli start, iar acea pereche este pasul de aplicare documentat. O modificare a comportamentului la nivel de ascultător, sau orice pagină descrie ca necesitând repornirea serviciului, este clasa în care repornirea unității este corectă.

Cele două comenzi nu sunt interschimbabile, așa că modul de eșec la ghicire este asimetric. Folosirea sacli start când era nevoie de o repornire completă lasă un proces vechi să servească în continuare configurația anterioară, ceea ce arată ca și cum setarea a fost ignorată. O repornire completă când ar fi fost suficient sacli start aruncă afară fiecare client conectat fără motiv.

A doua condiție: sesiunea ta este în tunel

Dacă administrezi Access Server prin VPN-ul pe care îl oferă, repornirea elimină conexiunea care îți transportă shell-ul. Comanda se poate termina după ce sesiunea ta moare, așa că ghicești dacă a funcționat. sacli start poate și el întrerupe scurt o sesiune din același motiv când componenta repornită îți gestionează traficul.

Ține deschisă o cale din afara benzii înainte de oricare dintre comenzi: o consolă a furnizorului, o consolă a hipervizorului sau o sesiune serială. Această condiție decide când rulezi comanda, nu care comandă, și ea este cea care transformă o modificare de două minute într-un raport de indisponibilitate.

A treia condiție: este acesta produsul la care te gândești

Access Server nu este Community OpenVPN. O instalare community rulează unități precum openvpn@server sau openvpn-client@profile, cu configurația în /etc/openvpn, iar sacli nu există acolo. Repornirea fiecărei unități cu openvpn în nume pe un host partajat este felul în care tuneluri fără legătură cad împreună.

Stabilește înainte să atingi ceva: systemctl status openvpnas --no-pager răspunde dacă Access Server este cel care rulează, sacli status îi listează componentele interne, iar systemctl list-units --type=service listează unitățile ale căror nume conțin openvpn. Dacă ultima comandă arată unități cu nume de profil, ești pe produsul community și restul de aici nu ți se aplică.

Aplică, apoi verifică dincolo de active

O unitate care raportează active are un proces în execuție, ceea ce nu este același lucru cu o cale de autentificare funcțională. După pasul de aplicare, verifică sacli status pentru componentele despre care te așteptai să fie repornite, confirmă că valoarea a fost salvată cu sacli ConfigQuery și apoi rulează o singură autentificare de client limitată cu un cont de test.

Încheie cu ceva la nivel de aplicație: ajunge la o resursă privată prin tunel, nu doar un ping către adresa publică a serverului. Un handshake care reușește în timp ce ruta împinsă sau setarea DNS sunt greșite va trece toate verificările serviciului și tot îl va dezamăgi pe cel care a raportat problema.

tutorialul furnizorului despre administrarea serviciilor este referința pentru ce operațiuni aparțin de sacli, și merită deschisă înainte de a decide că o repornire este opțiunea sigură.

Decizia într-o singură trecere

Parcurge aceste patru linii și oprește-te la prima care se potrivește:

• Pagina setării numește sacli start, sau tocmai ai executat ConfigPut: folosește sacli start.
• Pagina cere o repornire, sau modificarea atinge ascultători și nu proprietăți: folosește systemctl restart openvpnas.
• Shell-ul tău vine prin acest server: pregătește mai întâi accesul la consolă, apoi rulează comanda aleasă de cele două linii de mai sus.
• Verificare: sacli status, ConfigQuery pentru valoare, o autentificare, o resursă privată. Doar starea serviciului nu este linia de sosire.

Două dintre acele linii sunt verificări și două sunt acțiuni, și acesta este rostul ordinii. Dacă nu poți răspunde la întrebarea despre produs, oprește-te: comanda pe care urma să o rulezi aparține altei instalări, iar tunelul pe care îl dobori nu va fi cel la care te gândeai.