Isang management client lang: bakit itinataboy ng monitor mo ang GUI
Isang koneksyon lang ang tinatanggap ng management socket sa isang pagkakataon. Ang pangalawang subscriber ay nabigong kumonekta o nagnanakaw ng kontrol mula sa component na nagmamay-ari ng mga prompt.
Hinahawakan ng desktop GUI ang koneksyon ng management, kaya ang monitoring script na sumusubok magbukas ng sarili nitong koneksyon ay walang nababasa o, mas malala, tumitigil ang GUI sa pagsagot sa mga prompt. Ang karaniwang hinuha ay hindi matatag ang daemon. Sa daemon ng komunidad, sadyang may limitasyon: isang konektadong management client lang ang pinaglilingkuran ng control interface sa isang pagkakataon, at walang kinalaman ang bilang na iyon sa kung ilang user ang kayang dalhin ng VPN.
Isang socket, isang may-hawak
Isang konektadong client lang ang tinatanggap ng management channel. Kapag may pangalawang dumating habang aktibo ang una, naghihintay ito o tinatanggihan, at walang parallel na subscriber mode na nakatago sa likod ng isang opsyon. Ang pagdiskonekta sa kasalukuyang may-hawak ay nagpapahintulot sa daemon na tanggapin ang susunod, at iyon ay isang paglilipat, hindi isang pangalawang channel.
Ginagawa nitong katunggali ang bawat karagdagang tool. Kung hawak ng GUI ang koneksyon, ang polling script ay nabigong kumonekta o magtagumpay lamang pagkatapos sumuko ang GUI, at umuulit ang pagkakasunod-sunod sa susunod na muling pagkonekta. Kung ang script ang unang kumonekta, nawawala ng GUI ang control path nito at tumitigil ang mga prompt nito sa paggana. Wala sa mga tool ang nag-uulat ng salungatan, dahil nakikita lamang ng bawat isa ang sarili nitong bigong utos.
| What you need | Mechanism that fits | What it cannot do |
|---|---|---|
| Periodic list of connected clients | Status file written on an interval | Deliver events as they happen |
| Interactive prompts and session control | The single management connection | Serve two controllers at once |
| Multiple consumers of either | One owner process that fans out | Exist without you writing it |
Magpasya kung aling component ang may kontrol
Pumili ng isang may-hawak para sa interactive na channel at hayaang iyon lang ang kumonekta. Ang GUI na namamahala sa koneksyon, ang script na sumasagot sa mga authentication prompt, at ang controller na nagtatapos ng mga session ay pawang itinuturing na may-hawak, at isa lang ang makakapuwesto sa tungkulin.
Kapag hawak ng GUI ang koneksyon, gamitin ang integrasyon na inaalok ng GUI na iyon sa halip na makipaglaban dito. Ang pakikipagkarera sa may-hawak para sa socket ay gumagawa ng paminsan-minsang pagpalya na parang random sa mga user, at ang nagde-debug ay kadalasang nakikita lamang ang ikalawang kalahati ng karera. Itala kung aling proseso ang unang kumonekta pagkatapos ng reboot, dahil nagpapasya ang pagkakasunod-sunod na iyon kung sino ang panalo sa bawat pagkakataon. Ang monitor na nagsisimula bago ang GUI ay pananatilihin ang channel hanggang sumuko ang GUI.
Gumamit ng mga snapshot ng status para sa mga collector
Karamihan sa pangangailangan sa monitoring ay listahan, hindi usapan. Sinasagot iyon ng pana-panahong status file nang hindi hinahawakan ang control channel, at patuloy itong gumagana habang konektado ang GUI.
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixAng interval ang badyet ng pagkasariwa, kaya itakda ito sa aktwal na kailangan ng dashboard, hindi sa pinakamaliit na halagang mukhang ligtas. Mura ang snapshot na isinusulat tuwing ilang segundo; hindi mura ang script na muling kumokonekta sa control socket tuwing ilang segundo, dahil bawat muling pagkonekta ay nakikipagkarera sa may-hawak.
Ang snapshot ay hindi kasaysayan at hindi event feed. Ang mga koneksyong dumarating at umaalis sa loob ng isang interval ay hindi kailanman lumilitaw, kaya hindi matutugunan ang pangangailangan sa audit sa pamamagitan ng pag-poll sa file na nagsusulat sa sarili nito. Kung kailangan mong malaman kung kailanman kumonekta ang isang user, maling instrumento ang snapshot.
Ang fan-out ay disenyo, hindi mode
Kung talagang kailangan ng ilang consumer ang live na data ng management, maglagay ng isang pinagkakatiwalaang component sa harap ng socket at hayaang i-publish nito ang piniling-pili na mga obserbasyon sa iba. Ang component na iyon ang may hawak ng muling pagkonekta, ng mga authentication prompt, at ng desisyon kung ano ang ligtas na ilantad.
Buuin ito nang sadya: tukuyin kung aling mga query ang pinapayagan, i-log kung sino ang nagtanong, at iwasang maging remote control panel ang fan-out layer nang aksidente. Walang multi-client mode ang daemon na maaaring i-enable, at walang configuration line ang gumagawa nito. Ituring ang may-hawak na bahagi ng hangganan ng seguridad, dahil may hawak itong interface na makapagdiskonekta ng tao. Ang pag-restart nito ay dapat maging routine na operasyon na may dokumentadong recovery path.
Ituring ang socket na pribilehiyo, hindi metrics
Kayang idiskonekta ng management interface ang mga user, baguhin ang status at basahin ang mga event na nagbabanggit ng tao. Ang password nito ay nagpapatunay ng client at hindi nag-e-encrypt ng transport, kaya inilalantad ng network listener ang usapan sa kahit sinong makakapanood nito.
Mas mainam ang lokal na socket o mahigpit na limitadong listener, at tingnan kung aling proseso ang aktwal na tinutugunan ng collector mo, dahil may sariling management API ang mga server product na kakaiba ang kilos. Ang collector na nakatutok sa maling daemon ay gumagawa ng kumpiyansa pero maling konklusyon. Tiyakin ang path at ang owning process bago mag-debug ng query na walang ibinabalik.