Mengapa OpenVPN /24 kehabisan klien lebih cepat dari dugaan Anda

Pool yang dibangun di atas /24 dan berhenti menerima klien di sekitar enam puluhan berperilaku sesuai rancangan, bukan menabrak batas lisensi. Dengan net30, setiap klien mendapat tautan virtual point-to-point yang memakan empat alamat, jadi subnet 256 alamat mendukung sekitar seperempat dari yang disiratkan prefiks. Angka yang penting adalah alokasi, bukan alamat. Membaca prefiks sebagai jumlah klien adalah kesalahan yang memicu pencarian batas pengguna tersembunyi.

Dua topologi, dua model aritmetika, dan hanya satu di antaranya cocok dengan prefiks yang orang duga.

net30 menghabiskan empat alamat per klien

net30 mengalokasikan satu blok /30 per klien, karena setiap sesi dimodelkan sebagai tautan point-to-point dengan satu alamat di setiap ujung. Empat alamat masuk ke blok itu dan dua dapat dipakai, sehingga jumlah klien efektif adalah seperempat subnet. Pada /24 itu menyisakan 64 blok sebelum blok server sendiri dan alokasi tetap apa pun keluar. Batas atas yang dilaporkan mendekati 63 adalah aritmetika yang menembus, bukan maksimum yang dikonfigurasi.

Server juga perlu alokasinya sendiri, dan entri klien statis memakai blok baik klien itu terhubung maupun tidak. Keduanya mengurangi rentang dinamis tanpa mengubah prefiks yang Anda mulai.

Batas pool lebih penting daripada prefiks

Direktif server dapat menentukan pool yang lebih sempit daripada subnet yang disebutnya, dan skrip pembantu dapat meluas ke pengaturan tambahan yang tidak terlihat di profil yang Anda buka. Alamat tetap dari direktori client-config berada di dalam rentang itu dan tidak dapat diberikan dua kali. Prefiks menggambarkan ruang maksimum yang mungkin; pool efektif adalah apa yang sebenarnya ditawarkan konfigurasi yang berjalan.

Bandingkan keduanya sebelum menyimpulkan apa pun tentang kapasitas, karena rentang terkonfigurasi yang lebih kecil menjelaskan batas atas sama baiknya dengan topologi.

Temukan batas yang benar-benar menolak klien

Baca topologi dan pool efektif lebih dulu, lalu perhitungkan alokasi tetap dan alamat yang dicadangkan. Periksa juga max-clients dan setiap kontrol penerimaan di luar OpenVPN sebelum menyalahkan ruang alamat. Terakhir, cocokkan pesan server sendiri pada saat penolakan dengan kandidat tersebut. Pesan itu menyebut kendalanya; jumlahnya hanya mempersempit bidang.

Penolakan yang datang dengan kesalahan konkurensi dan penolakan yang datang dengan kesalahan alokasi punya perbaikan berbeda, dan menebak di antara keduanya membuang jendela pemeliharaan.

Mengubah topologi mengubah rencana alamat

Beralih ke topologi subnet memberi setiap klien satu alamat alih-alih satu blok, yang merupakan langkah tepat ketika prefiks benar-benar terlalu kecil. Ini juga mengubah arti parameter alamat klien, jadi setiap alokasi yang dipatok dan setiap berkas khusus klien harus diturunkan ulang alih-alih dinomori ulang dengan tangan. Rencanakan rentang baru, migrasikan entri statis, dan perbarui rute yang merujuknya.

Peralihan itu bukan sinonim dari konfigurasi lama. Perlakukan sebagai perubahan rencana alamat dengan tinjauannya sendiri, dan perkirakan setidaknya satu klien mempertahankan alamat dari skema sebelumnya.

Ukur pool dari rencana, bukan dari mask

Pilih ukuran dari jumlah klien bersamaan ditambah ruang untuk penyambungan ulang dan pengujian, lalu pilih prefiks terkecil yang menutupinya di bawah topologi yang dipilih. Melebarkan ke /16 untuk menyelesaikan batas enam puluh klien menukar masalah kapasitas dengan masalah perutean dan tumpang tindih, karena rentang privat yang lebih besar lebih mungkin bertabrakan dengan sesuatu yang sudah dijangkau klien.

Dokumentasikan topologi, pool, alokasi tetap, dan batas klien yang dihasilkan secara bersama. Pertanyaan kapasitas berikutnya lalu menjadi aritmetika alih-alih penyelidikan.