Mengapa /24 OpenVPN kehabisan klien lebih awal daripada jangkaan

Pool yang dibina pada /24 dan berhenti menerima klien pada lingkungan enam puluhan berkelakuan seperti direka, bukan mencapai had lesen. Di bawah net30 setiap klien diberikan pautan titik-ke-titik maya yang menggunakan empat alamat, jadi subnet 256 alamat menyokong kira-kira satu perempat daripada apa yang dicadangkan oleh awalan. Jumlah yang penting ialah peruntukan, bukan alamat. Membaca awalan sebagai bilangan klien ialah kesilapan yang menyebabkan pencarian had pengguna tersembunyi.

Dua topologi, dua model aritmetik, dan hanya satu daripadanya sepadan dengan awalan yang orang andaikan.

net30 menggunakan empat alamat bagi setiap klien

net30 memperuntukkan blok /30 bagi setiap klien, kerana setiap sesi dimodelkan sebagai pautan titik-ke-titik dengan satu alamat di setiap hujung. Empat alamat masuk ke dalam blok itu dan dua boleh digunakan, itulah sebabnya bilangan klien berkesan ialah satu perempat daripada subnet. Pada /24 itu meninggalkan 64 blok sebelum blok milik pelayan dan sebarang penugasan tetap keluar. Had yang dilaporkan sekitar 63 ialah aritmetik yang terserlah, bukan maksimum yang dikonfigurasikan.

Pelayan juga memerlukan peruntukannya sendiri, dan entri klien statik menggunakan blok sama ada klien itu menyambung atau tidak. Kedua-duanya mengurangkan julat dinamik tanpa menukar awalan yang anda mulakan.

Sempadan pool lebih penting daripada awalan

Arahan pelayan mungkin menentukan pool yang lebih sempit daripada subnet yang dinamakannya, dan skrip pembantu boleh berkembang ke tetapan tambahan yang tidak kelihatan dalam profil yang anda buka. Alamat tetap daripada direktori client-config berada di dalam julat itu dan tidak boleh diberikan dua kali. Awalan menerangkan ruang maksimum yang mungkin; pool berkesan ialah apa yang sebenarnya ditawarkan oleh konfigurasi yang sedang berjalan.

Bandingkan kedua-duanya sebelum membuat kesimpulan tentang kapasiti, kerana julat terkonfigurasi yang lebih kecil menjelaskan had itu sama baiknya seperti topologi.

Cari had yang sebenarnya menolak klien

Baca topologi dan pool berkesan dahulu, kemudian ambil kira penugasan tetap dan alamat terpelihara. Sebelum menyalahkan ruang alamat, periksa max-clients dan sebarang kawalan kemasukan di luar OpenVPN. Akhir sekali, padankan mesej pelayan sendiri pada saat penolakan dengan calon-calon itu. Mesej itu menamakan kekangan; jumlah hanya menyempitkan bidang.

Penolakan yang datang dengan ralat keserentakan dan penolakan yang datang dengan ralat peruntukan mempunyai pembetulan berbeza, dan meneka antara keduanya membazirkan tetingkap penyelenggaraan.

Menukar topologi mengubah pelan alamat

Bertukar kepada topologi subnet memberi setiap klien satu alamat dan bukannya satu blok, yang merupakan langkah betul apabila awalan benar-benar terlalu kecil. Ia juga mengubah maksud parameter alamat klien, jadi setiap penugasan yang dipaku dan setiap fail khusus klien mesti diterbitkan semula dan bukan dinomborkan semula dengan tangan. Rancang julat baharu, migrasi entri statik, dan kemas kini laluan yang merujuknya.

Pertukaran itu bukan sinonim bagi konfigurasi lama. Layaninya sebagai perubahan pelan alamat dengan semakan tersendiri, dan jangkakan sekurang-kurangnya satu klien menyimpan alamat daripada skema sebelumnya.

Saiz pool daripada pelan, bukan daripada topeng

Pilih saiz daripada bilangan klien serentak ditambah ruang lega untuk sambung semula dan ujian, kemudian pilih awalan terkecil yang meliputinya di bawah topologi yang dipilih. Melebarkan kepada /16 untuk menyelesaikan had enam puluh klien menukar masalah kapasiti kepada masalah penghalaan dan pertindihan, kerana julat peribadi yang lebih besar lebih cenderung berlanggar dengan sesuatu yang sudah dicapai oleh klien.

Dokumenkan topologi, pool, penugasan tetap dan had klien yang terhasil bersama-sama. Persoalan kapasiti seterusnya kemudian menjadi aritmetik dan bukan penyiasatan.