Pagpaplano ng maintenance window ng OpenVPN nang hindi nawawala ang host

Ang pag-restart ng serbisyo ng VPN ay nagtatapos sa bawat session na gumagamit nito, kaya ang window ay kailangang itayo sa paligid ng mga usapan at hindi sa paligid ng package manager. Kailangan ng mga user ng sapat na abiso para tapusin ang sensitibong trabaho, at kailangan mo ng daan pabalik na hindi umaasa sa tunnel na titigil mo. Lahat ng iba sa playbook ay naroroon para maging pamahalaan ang dalawang katotohanang iyon. Laktawan ang alinman sa mga ito at ang rutinang update ay nagiging outage na walang labasan.

Ang pagkakasunod-sunod sa ibaba ay sinadya: bawat yugto ay gumagawa ng kailangan ng susunod na yugto, at anumang yugto ay maaaring tapusin ang pagbabago bago ito magsimula.

Kunin ang serbisyong umiiral bago ito baguhin

Basahin ang naka-install na unit at hindi ang inaakala mong isinulat mo: systemctl cat [email protected] ay nagpi-print ng unit at anumang drop-in, at systemctl show [email protected] -p ExecStart -p User -p WorkingDirectory ay nagpapakita kung ano talaga ang tumatakbo at bilang sino. Itanong ang binary na pinangalanan ng unit, dahil ang openvpn --version mula sa isang shell ay maaaring tumukoy sa ibang build. Itala ang landas ng profile at bawat file na tinutukoy nito.

Pansinin din ang mga socket na nakikinig: ss -lunp | grep 1194 ay nagsasabi kung anong address at protocol ang pag-aari ng daemon ngayon. Kung ang sagot ay hindi ang iminumungkahi ng profile, isang drop-in o environment file ang nangingibabaw dito, at mamanahin ng upgrade ang sorpresang iyon.

Bumuo ng recovery set na magagamit ng iba

Ang recovery set ay dapat magamit ng katrabaho nang 03:00 nang walang konteksto mo. Isama ang epektibong configuration kasama ang bawat file na tinutukoy, ang trust at revocation material sa ilalim ng kontrol ng may-ari ng PKI, ang mga assignment at hook ng bawat kliyente, at ang eksaktong mga bersyon ng package na naka-install ngayon. Ang kopya ng isang pangalan ng file ay hindi configuration. Itabi ito sa lugar na maaabot ng on-call operator nang walang VPN.

Naaangkop din ang mga kontrol sa access sa set na iyon, dahil naglalaman ito ng mga pribadong key o backend credential. Huwag muling buuin ang CA o muling maglabas ng mga pagkakakilanlan dahil lang nagbago ang bersyon ng package.

Magsanay sa pilot listener gamit ang totoong kliyente

Patakbuhin ang kandidatong release sa hiwalay na listener na may sariling plano sa port at address, hindi sa tabi ng production instance sa parehong socket. Kumonekta gamit ang mga client engine na talagang pinapatakbo ng mga user mo, kasama ang mahirap. Suriin ang pagtatalaga ng address, ang pushed DNS, isang aplikasyong mahalaga, at isang landas na dapat manatiling naka-block. Ang mga custom hook ay dapat tumakbo sa tunay na konteksto ng pribilehiyo at filesystem ng serbisyo, dahil walang pinapatunayan ang root shell tungkol sa kanila.

Basahin ang release notes para sa mga pagbabago sa pag-uugali, hindi lang para sa mga bagong feature. Nagbabago ang mga default ng cipher at TLS sa pagitan ng mga bersyon, at ang profile na nagpa-parse pa ay maaari pa ring mabigo sa handshake. Kung kailangan ng upgrade ang mga pagbabago sa profile o certificate, ihanda iyon bilang sariling hakbang sa halip na isama sa pag-update ng package.

Lumipat nang isang beses, mula sa landas sa labas ng tunnel

Simulan ang window mula sa console o management network na hindi dumadaan sa serbisyo. Kumpirmahin na naabisuhan ang mga user at alam ng ikalawang operator kung paano mag-rollback. Ilapat ang inihandang pagbabago sa pamamagitan ng may-ari nito, pagkatapos ay i-restart gamit ang sudo systemctl restart [email protected] at sundan ang journal gamit ang journalctl -u openvpn-server@office -b -f. Sapat ang reload kapag mga depinisyon ng unit lang ang nagbago; ang binagong profile ay nangangailangan ng restart ng proseso.

Asahan na muling kokonekta ang bawat kliyente, at asahan na ang ilang session ng aplikasyon ay hindi magpapatuloy. I-coordinate ang malinis na paghinto sa mga workload na hindi makakayanan iyon.

Tanggapin o i-rollback, pagkatapos ay sabihin sa mga user kung ano ang nagbago

Ang pagtanggap ay isang bagong login dagdag ang isang tunay na operasyon dagdag ang mga paghihigpit na may bisa pa. Ang aktibong unit at berdeng status line ay mga katotohanan ng proseso lamang. Kung mabigo ang mga pamantayan sa loob ng window, i-rollback gamit ang inihandang paraan, hindi sa pamamagitan ng pagbalik ng isang file at pag-asa; ang binagong binary o patakaran ng serbisyo ay nakakaligtas sa pagbalik ng configuration. Panatilihin ang anumang pagbawi o pagbabago ng awtorisasyon na ginawa sa window para hindi mabawi ng rollback ang gawaing seguridad.

Itala ang mga bersyon, pagbabago ng profile at resulta ng pagtanggap para sa susunod na operator, iretiro ang pilot listener, at sabihin sa mga user kung aling profile ang gagamitin ngayon. Ang window na nagtatapos nang wala ang talaang iyon ay muling pag-uusapan sa susunod na update.