OpenVPN Access Server: i-restart ang daemon o ilapat ang setting

Dalawang utos ang idinidikit para sa tila parehong gawain sa OpenVPN Access Server, at magkaiba ang ginagawa nila. Hinihinto at sinisimulan ng systemctl restart openvpnas ang buong produkto. Itinataas ng sacli start ang mga panloob na serbisyong bumabasa ng configuration na kakabago mo lang. Ang pagpili sa pagitan nila ay hindi usapin ng lasa: nakadepende ito sa sinasabi ng dokumentasyon ng setting mismo, kung dumadaan ang session mo sa server na i-restart mo, at kung tama ba ang produktong tinitingnan mo.

Dalawang antas, isang daemon

Tumatakbo ang Access Server bilang isang systemd unit, openvpnas, at binabantayan ng daemon na iyon ang mga panloob na serbisyo sa likod ng web interface at ang mga tagapakinig ng VPN. Ang sacli ang command-line interface sa parehong installation, sa /usr/local/openvpn_as/scripts/sacli, at kaya nitong simulan, ihinto at tanungin ang mga panloob na bahaging iyon nang hindi pinapalitan ang unit.

Kaya may dalawang utos. Ang restart ng daemon ay nagpapatakbo muli ng lahat, kasama ang prosesong nagtatapos sa mga tunnel ng kliyente. Hinihiling ng sacli start sa tumatakbong daemon na itaas ang mga bahagi nito upang basahin ang bagong configuration, at iyon ang talagang kailangan ng karamihan ng pagbabago sa property.

Unang kondisyon: ano ang sinasabi ng dokumentasyon ng setting

Basahin ang pahina ng setting na binago mo, hindi ng setting na binago mo noong nakaraang buwan. Pagkatapos ng property na isinulat sa ConfigPut ay karaniwang sumusunod ang sacli start, at ang pares na iyon ang dokumentadong hakbang sa paglalapat. Ang pagbabago sa pag-uugali sa antas ng tagapakinig, o anumang inilalarawan ng pahina na nangangailangan ng restart ng serbisyo, ang klase kung saan tama ang restart ng unit.

Hindi mapagpapalit ang dalawang utos, kaya ang paraan ng pagkabigo kapag naghula ay hindi simetriko. Ang paggamit ng sacli start kapag kailangan ang buong restart ay nag-iiwan ng lumang prosesong naglilingkod pa sa dating configuration, na mukhang binalewala ang setting. Ang buong restart kapag sapat na ang sacli start ay nagtataboy sa bawat konektadong kliyente nang walang dahilan.

Ikalawang kondisyon: nasa loob ba ng tunnel ang session mo

Kung pinamamahalaan mo ang Access Server sa pamamagitan ng VPN na ibinibigay nito, inaalis ng restart ang koneksyong nagdadala ng shell mo. Maaaring matapos ang utos pagkatapos mamatay ang session mo, kaya naghuhula ka kung gumana ito. Sa parehong dahilan, ang sacli start ay maaari ring saglit na gambalain ang session kapag ang bahaging ini-restart ay humahawak ng trapik mo.

Panatilihing bukas ang isang daang labas ng banda bago ang alinman sa mga utos: console ng provider, console ng hypervisor, o serial session. Ang kondisyong ito ang nagtatakda kung kailan mo tatakbuhin ang utos, hindi kung alin, at ito ang nagpapalit ng dalawang minutong pagbabago sa ulat ng pagkawala ng serbisyo.

Ikatlong kondisyon: ito ba ang produktong inaakala mo

Ang Access Server ay hindi Community OpenVPN. Ang community installation ay nagpapatakbo ng mga unit tulad ng openvpn@server o openvpn-client@profile, ang configuration ay nasa /etc/openvpn, at walang sacli doon. Ang pag-restart ng bawat unit na may openvpn sa pangalan sa isang shared host ang paraan kung paano sabay na bumabagsak ang mga tunnel na walang kaugnayan.

Tukuyin bago ka humawak ng kahit ano: sinasagot ng systemctl status openvpnas --no-pager kung Access Server ang tumatakbo, inililista ng sacli status ang mga panloob na bahagi nito, at inililista ng systemctl list-units --type=service ang mga unit na may openvpn sa pangalan. Kung ang huling utos ay nagpapakita ng mga unit na may pangalang profile, nasa community product ka at hindi na applicable sa iyo ang natitira rito.

Ilapat, pagkatapos ay i-verify sa kabila ng active

Ang unit na nag-uulat ng active ay may tumatakbong proseso, na hindi kapareho ng gumaganang landas ng authentication. Pagkatapos ng hakbang sa paglalapat, suriin ang sacli status para sa mga bahaging inaasahan mong i-restart, kumpirmahin na na-save ang halaga sa sacli ConfigQuery, at pagkatapos ay magpatakbo ng isang limitadong pag-login ng kliyente gamit ang test account.

Tapusin sa isang bagay sa antas ng application: maabot ang isang pribadong resource sa pamamagitan ng tunnel, hindi lang ping sa pampublikong address ng server. Ang handshake na nagtatagumpay habang mali ang itinulak na ruta o ang setting ng DNS ay dadaan sa lahat ng pagsusuri ng serbisyo at pababagsakin pa rin ang taong nag-ulat ng problema.

ang tutorial ng provider sa pamamahala ng serbisyo ang sanggunian kung aling mga operasyon ang pag-aari ng sacli, at sulit itong buksan bago mo pagpasyahan na ang restart ang ligtas na opsyon.

Ang desisyon sa isang daan

Dumaan sa apat na linyang ito at huminto sa unang tugma:

• Binanggit ng pahina ng setting ang sacli start, o kakapatakbo mo lang ng ConfigPut: gamitin ang sacli start.
• Kailangan ng pahina ang restart, o ang pagbabago ay tumatama sa mga tagapakinig at hindi sa property: gamitin ang systemctl restart openvpnas.
• Dumadaan ang shell mo sa server na ito: ayusin muna ang access sa console, pagkatapos ay patakbuhin ang utos na pinili ng dalawang linya sa itaas.
• Beripikasyon: sacli status, ConfigQuery para sa halaga, isang pag-login, isang pribadong resource. Ang kalagayan ng serbisyo lamang ay hindi ang finish line.

Dalawa sa mga linyang iyon ay pagsusuri at dalawa ay aksyon, at iyon ang punto ng pagkakasunod-sunod. Kung hindi mo masagot ang tanong tungkol sa produkto, huminto: ang utos na tatakbuhin mo ay pag-aari ng ibang installation, at ang tunnel na ibabagsak mo ay hindi ang sinadya mo.