Ano ang tunay na naisasurvive ng persist-tun at persist-key sa OpenVPN
Sinasaklaw ng dalawang opsyon ang malambot na pag-restart sa loob ng buhay na proseso. Hindi nila pinapanatili ang interface pagkatapos ng paghinto, at hindi sila patakaran ng pagharang sa trapiko.
Ang paghinto sa serbisyo ay nag-aalis ng interface kahit nakatakda ang persist-tun. Ito ang opsyon na gumagana ayon sa dokumentado, hindi pagkabigo. Inilalarawan ng opsyon ang isang landas ng restart sa loob ng tumatakbong proseso, at ang systemctl stop ay hindi ang landas na iyon.
Basahin ang dalawang pangalan nang magkasama at ang disenyo ay nagiging malinaw. Ang isa ay nagpapanatili ng deskriptor, ang isa ay nagpapanatili ng materyal ng susi, at pareho silang umiiral dahil sa nangyayari pagkatapos bitawan ang mga pribilehiyo.
Ang dalawang mapagkukunan at ang reset na kinabibilangan nila
OpenVPN ay naghuhudyat ng sarili nitong restart sa dalawang karaniwang sitwasyon. Ang tahasang SIGUSR1 ay gumagawa niyon, at ang ping-restart na pinukaw ng patay na kapares ay gumagawa rin ng pareho. Pareho nilang pinapanatiling buhay ang proseso at muling pinapatakbo ang setup ng koneksyon, at doon nakukuha ng mga opsyon ang kanilang lugar.
| Event | TUN/TAP device | Key and auth files | Addresses and routes | up/down hooks |
|---|---|---|---|---|
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itself | survives only with persist-tun | survive only with persist-key | survive with the device, otherwise rebuilt | run again only when restart hooks are enabled |
Configuration reload, SIGHUP | recreated | re-read from disk | rebuilt once the device returns | run again |
| Service stop | lost | re-read at the next start | removed | run at the next start |
Tanging ang hilera ng malambot na restart ang binabago ng dalawang opsyon na ito, at ang trabahong nilalaktawan nila ay ang mamahaling bahagi sa abalang link. Ang muling pagbukas ng device ay nagwawasak ng mga address at ruta na nakakabit dito, at ang muling pagbuo sa mga ito ay maaaring magbaba ng mga packet na nasa daan nang magsimula ang restart. Ang paghinto ay sumisira sa parehong mga bagay nang walang anumang opsyon na mapanatili sila.
Bakit talaga umiiral ang mga opsyon na ito
Ang pinatigas na OpenVPN server ay karaniwang nagsisimula bilang root, binubuksan ang mga susi at device nito, pagkatapos ay bumababa sa isang user na walang pribilehiyo. Pagkatapos ng pagbabang iyon, ang ilang operasyon ay nawawala na lang. Ang pagbasa ng key file na mode 0600, paggawa ng network interface, o pagbabago ng mga ruta ay maaaring lahat tanggihan.
Kung wala ang mga opsyon na persist, ang kapares na tahimik nang sapat katagal para pukawin ang ping-restart ay pipilitin ang eksaktong mga operasyong iyon. Mabibigo ang muling pagkonekta kahit walang nagbago sa configuration. Ang proseso ay magmumukhang namamatay nang walang dahilan, at ang log ay magpapakita ng error sa pahintulot sa halip na error sa network.
Sa mga ito, muling ginagamit ng malambot na restart ang nakuha na ng pribilehiyadong yugto. Walang mahika at walang naisasurvive ang proseso. Ang pagkuha ng mga mapagkukunan ay ipinagpaliban lamang.
Basahin ang unang error, hindi ang huli
Kapag nabigo ang restart, basahin ang unang error sa halip na ang huli. Ang protektadong susi, auth file, interface ioctl at panlabas na hook ay apat na magkakaibang mapagkukunan. Ang pagpapanatili ng isa ay walang sinasabi tungkol sa pag-access sa iba. Ang hook na tumatawag ng firewall tool ay nangangailangan pa rin ng mga pribilehiyong hinihingi ng tool na iyon.
May sariling switch ang mga hook. Ang manwal ng OpenVPN ay ipinares ang mga opsyon na persist sa up-restart, na nagpapasya kung ang up at down script ay muling tatakbo pagkatapos ng restart. Kaya ang interface na nanatiling nakataas ay walang sinasabi sa iyo tungkol sa kung na-refresh ang iyong resolver integration.
# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'
# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0
Ang pares ng mga command na iyon ay naghihiwalay sa dalawang mode ng pagkabigo sa ilang segundo. Ang interface na naroroon ngunit kulang ang mga ruta ay problema sa hook o ruta. Ang interface na nawala ay nangangahulugang tunay na natapos ang proseso.
Ang pinanatiling interface ay hindi kill switch
Kung ang pangangailangan ay hindi kailanman lalabas ang trapiko sa labas ng tunnel, hindi iyon ibinibigay ng pinanatiling device. Ang mga ruta para sa kabilang pamilya ng address, pangalawang default na ruta, at ang kaso kung saan ganap na lumabas ang proseso ay nananatiling lahat sa labas ng saklaw ng opsyon.
Pangunahan ang dalawang pangangailangan nang hiwalay. Ang pagpapanatili ng bagay ng tunnel sa pagitan ng mga muling pagkonekta ay kaginhawahan para sa daemon. Ang pagharang sa labasan kapag bumagsak ang tunnel ay patakaran ng firewall na may sariling mga tuntunin at sariling pagsubok. Ang pagsasama ng mga ito ay gumagawa ng configuration na mukhang nagtatanggol at kumikilos na parang muling pagkonekta sa pinakamabuting pagsisikap.
Pangalanan ang kaganapan bago ito i-diagnose. Ang malambot na restart, nabigong pagtatangka ng koneksyon at paghinto ng serbisyo ay tatlong kaganapan na may tatlong pag-uugali, at tanging ang una ang inilalarawan ng mga opsyon na ito.