Hanya satu klien manajemen: mengapa monitor Anda mengeluarkan GUI
Soket manajemen menerima satu koneksi sekaligus. Pelanggan kedua gagal terhubung atau merebut kendali dari komponen yang memiliki prompt.
GUI desktop memegang koneksi manajemen, jadi skrip pemantauan yang mencoba membuka koneksinya sendiri tidak membaca apa pun atau, lebih buruk, GUI berhenti merespons prompt. Kesimpulan yang biasa diambil adalah daemon tidak stabil. Pada daemon komunitas, batasannya memang disengaja: antarmuka kendali melayani satu klien manajemen yang terhubung dalam satu waktu, dan angka itu tidak ada hubungannya dengan berapa banyak pengguna yang dapat diangkut VPN.
Satu soket, satu pemegang
Kanal manajemen menerima satu klien yang terhubung. Ketika klien kedua datang saat yang pertama aktif, ia menunggu atau ditolak, dan tidak ada mode pelanggan paralel yang tersembunyi di balik opsi. Memutuskan pemegang saat ini memungkinkan daemon menerima berikutnya, dan itu adalah serah terima, bukan kanal kedua.
Itu menjadikan setiap alat tambahan sebagai pesaing. Jika GUI memiliki koneksi, skrip polling gagal terhubung atau baru berhasil setelah GUI menyerah, dan urutannya berulang pada penyambungan ulang berikutnya. Jika skrip terhubung lebih dulu, GUI kehilangan jalur kendalinya dan prompt-nya berhenti bekerja. Tidak ada alat yang melaporkan konflik, karena masing-masing hanya melihat perintahnya sendiri yang gagal.
| 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 |
Tentukan komponen mana yang memiliki kendali
Pilih satu pemegang untuk kanal interaktif dan biarkan hanya itu yang terhubung. GUI yang mengelola koneksi, skrip yang menjawab prompt autentikasi, dan pengendali yang mengakhiri sesi semuanya dihitung sebagai pemegang, dan hanya satu yang dapat memegang peran itu.
Ketika GUI memiliki koneksi, gunakan integrasi yang disediakan GUI itu alih-alih melawannya. Berlomba dengan pemegang untuk soket menghasilkan kegagalan berselang yang tampak acak bagi pengguna, dan orang yang men-debug biasanya hanya melihat paruh kedua perlombaan. Catat proses mana yang terhubung lebih dulu setelah reboot, karena urutan itu menentukan siapa yang menang setiap kali. Monitor yang mulai sebelum GUI akan mempertahankan kanal sampai GUI menyerah.
Gunakan snapshot status untuk para kolektor
Sebagian besar kebutuhan pemantauan memerlukan daftar, bukan percakapan. Berkas status berkala menjawabnya tanpa menyentuh kanal kendali, dan tetap berfungsi selama GUI tetap terhubung.
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixInterval adalah anggaran kesegaran, jadi tetapkan sesuai yang benar-benar dibutuhkan dasbor, bukan pada nilai terkecil yang terlihat aman. Snapshot yang ditulis setiap beberapa detik murah; skrip yang menyambung ulang ke soket kendali setiap beberapa detik tidak murah, karena setiap penyambungan ulang bersaing dengan pemegang.
Snapshot bukan riwayat dan bukan aliran peristiwa. Koneksi yang datang dan pergi dalam satu interval tidak pernah muncul, jadi persyaratan audit tidak dapat dipenuhi dengan melakukan polling berkas yang menimpa dirinya sendiri. Jika Anda perlu tahu apakah seorang pengguna pernah terhubung sama sekali, snapshot adalah instrumen yang salah.
Penyebaran adalah desain, bukan mode
Jika beberapa konsumen benar-benar membutuhkan data manajemen langsung, letakkan satu komponen tepercaya di depan soket dan biarkan komponen itu menerbitkan pengamatan yang dipilih secara sempit kepada yang lain. Komponen itu memiliki penyambungan ulang, prompt autentikasi, dan keputusan tentang apa yang aman untuk diekspos.
Bangunlah dengan sengaja: tetapkan kueri mana yang diizinkan, catat siapa yang bertanya, dan hindari mengubah lapisan penyebaran menjadi panel kendali jarak jauh secara tidak sengaja. Daemon tidak memiliki mode multi-klien untuk diaktifkan, dan tidak ada baris konfigurasi yang membuatnya. Perlakukan pemegang sebagai bagian dari batas keamanan, karena ia memegang antarmuka yang dapat memutus orang. Menyalakannya ulang seharusnya menjadi operasi rutin dengan jalur pemulihan yang terdokumentasi.
Perlakukan soket sebagai hak istimewa, bukan sebagai metrik
Antarmuka manajemen dapat memutus pengguna, mengubah status, dan membaca peristiwa yang menyebut nama orang. Kata sandinya mengautentikasi klien dan tidak mengenkripsi transport, jadi pendengar jaringan mengekspos percakapan kepada siapa pun yang dapat mengamatinya.
Utamakan soket lokal atau pendengar yang dibatasi secara ketat, dan periksa proses mana yang sebenarnya dituju kolektor Anda, karena produk server membawa API manajemennya sendiri yang berperilaku berbeda. Kolektor yang diarahkan ke daemon yang salah menghasilkan kesimpulan yang yakin tetapi keliru. Pastikan jalur dan proses pemiliknya sebelum men-debug kueri yang tidak mengembalikan apa pun.