Menghubungkan RADIUS ke OpenVPN: plugin atau pengait skrip?

Plugin masih disarankan di utas yang lebih tua daripada build saat ini, dan ia gagal saat dimuat di server yang dikompilasi kemarin. Ini bukan kesalahan konfigurasi yang bisa diperbaiki dengan jalur. Plugin dan pengait skrip menyelesaikan masalah yang sama di lapisan berbeda, dan berpindah dari satu ke yang lain mengubah apa yang harus dipasang, apa yang berjalan dengan hak istimewa server, dan apa yang sebenarnya dikatakan login gagal kepada Anda.

Mitos: plugin adalah jalur yang didukung

Plugin adalah objek bersama yang dimuat ke dalam proses OpenVPN, jadi ia harus cocok dengan antarmuka yang diekspos proses itu. Build berubah, pengemasan berubah, dan pustaka yang dikompilasi untuk antarmuka lama akan menolak dimuat. Tidak ada yang bisa menjembatani celah itu dalam konfigurasi server, karena itu saran "cukup pasang radiusplugin" berakhir dengan server yang tidak mau menyala.

Pengait skrip justru berada di luar proses. OpenVPN menjalankan sebuah program, menyerahkan kredensial kepadanya, dan membaca kembali putusan. Pemisahan itulah yang membuatnya bertahan melewati peningkatan, dan itu juga yang menjadikannya tanggung jawab Anda dengan cara yang tidak pernah dimiliki plugin.

Tidak ada pendekatan yang lebih aman secara konstruksi. Yang satu menjalankan kode asing di dalam daemon; yang lain menjalankan kode Anda di sampingnya dengan kredensial di tangan. Pertanyaan yang benar adalah risiko mana dari keduanya yang benar-benar bisa Anda operasikan.

Apa yang diikat plugin

Plugin membawa berkas konfigurasinya sendiri dengan host RADIUS, rahasia bersama, jumlah percobaan ulang, dan batas waktu, dan konfigurasi server merujuknya dengan satu baris. Penanganan kredensial tetap di dalam proses server, yang berarti kata sandi tidak pernah melintasi batas proses yang harus diamankan administrator.

Biayanya adalah keterikatan. Setiap peningkatan OpenVPN berisiko antarmuka yang tidak kompatibel, dan setiap distribusi yang membangun ulang paket berisiko menghasilkan pustaka yang tidak lagi cocok. Ketika itu terjadi, kegagalan bersuara keras dan seketika, dan itulah satu-satunya belas kasihan dari desain ini.

Jika plugin semacam itu masih dimuat di build Anda, ia bisa menjadi permukaan operasional yang lebih kecil. Pastikan antarmuka tempat ia dibangun, tahan ia dipatok pada build yang Anda uji, dan perlakukan setiap peningkatan sebagai perubahan yang menuntut uji login penuh, bukan pembaruan paket rutin.

Apa yang sebenarnya dipercaya pengait skrip

Pengait dikonfigurasi dengan auth-user-pass-verify dan mekanisme pengiriman: variabel lingkungan atau berkas sementara. Dalam bentuk lingkungan, OpenVPN menuntut script-security 3, tingkat terdokumentasi yang mengizinkan paparan kata sandi ke skrip. Tingkat itu adalah pelemahan bawaan yang disengaja, dan harus diperlakukan sebagai izin dengan alasan yang dilampirkan.

Semua yang disentuh skrip mewarisi kepercayaan itu. Berkas itu harus dimiliki root, tidak dapat ditulis oleh grup atau pihak lain, dirujuk dengan jalur absolut, dan bebas dari tempat mana pun di mana nilai tak tepercaya mencapai shell. Bungkus setiap variabel dengan tanda kutip, tolak karakter tak terduga, dan jangan pernah menyusun perintah dari nama pengguna yang diberikan. Skrip yang berjalan sebagai root pada setiap upaya login layak ditinjau sekali justru karena keempat sifat itu.

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

Bentuk pengiriman berkas menghindari masalah pewarisan lingkungan dan menyerahkan kredensial ke skrip melalui berkas sementara dengan izin terbatas. Jika klien Anda mendukungnya, biasanya ini bawaan yang lebih baik, meskipun menambah satu objek lagi untuk dibersihkan saat gagal.

Kode keluar menentukan apakah Anda gagal terbuka

Status keluar skrip adalah putusannya: nol menerima, bukan nol menolak. Pola yang menimbulkan masalah adalah skrip shell yang hanya menerima ketika balasan RADIUS memuat token penerimaan tertentu dan mengembalikan kegagalan untuk semua hal lain, karena itu melebur tiga peristiwa berbeda menjadi satu jawaban. Kata sandi salah, server tak terjangkau, dan balasan cacat semuanya menjadi penolakan yang sama.

Pisahkan kasus itu di dalam skrip meskipun pengait hanya bisa mengembalikan terima atau tolak. Catat hasil backend secara terpisah, beri peringatan pada batas waktu dan kesalahan transport, dan buat jelas di pemantauan ketika autentikasi gagal karena layanan mati, bukan karena pengguna salah mengetik.

Dua kebiasaan menjaga sisanya waras. Jika RADIUS adalah otoritas, ia harus menjadi satu-satunya tempat kata sandi diperiksa, karena tabel bayangan menciptakan dua jawaban untuk pertanyaan yang sama dan yang kedua adalah permukaan serangan yang tidak diawasi siapa pun. Dan ingat pengait dipanggil lagi pada setiap percobaan ulang, jadi skrip lambat dengan klien tak sabar menjadi penguat bagi penebakan kata sandi kecuali Anda menambahkan jeda atau kebijakan di sisi RADIUS.

Apa yang Anda lepaskan saat sertifikat hilang

Banyak penerapan berbentuk ini mematikan pemeriksaan sertifikat klien sepenuhnya, meninggalkan nama pengguna dan kata sandi sebagai seluruh klaim klien. Yang hilang dengan pengaturan itu adalah identitas berbasis sertifikat. Kanal tetap terenkripsi, tetapi satu-satunya yang menamai klien adalah putusan RADIUS. Apa pun di hilir yang dulu bertumpu pada subjek sertifikat kini harus bertumpu pada nama pengguna.

Pertahankan perlindungan kanal kendali agar rekan yang tidak terautentikasi tidak dapat menyelidiki atau membanjiri jabat tangan, dan gunakan username-as-common-name ketika konfigurasi per pengguna bergantung pada nama umum. Gateway terkelola sering menyelesaikan ini dengan cara lain, mengakhiri autentikasi sertifikat di gateway yang berbicara EAP-TLS dengan RADIUS, dan dalam kasus itu tidak satu pun direktif server ini berlaku. Salin model yang didokumentasikan platform Anda sendiri, bukan model dari produk tetangga. Direktif yang penting cukup berbeda sehingga mencampurnya menghasilkan konfigurasi yang terurai lalu tidak mengautentikasi siapa pun.