Server OpenVPN dengan nopool: nyatakan rentang pool eksplisit

Pembantu server mengonfigurasi subnet lalu mengisinya dengan pool dinamis pilihannya sendiri. Bawaan itu nyaman sampai beberapa alamat harus tetap di luar alokasi, baik dicadangkan untuk penetapan tetap maupun ditahan untuk segmen mendatang. Menekan pool otomatis dan menyatakan rentangnya sendiri memerlukan dua baris dan satu keputusan sadar tentang alamat mana yang bukan untuk alokasi. Sisanya adalah disiplin operasional: inventaris, terapkan, verifikasi, kembalikan.

Ini perubahan pada layanan yang sedang berjalan, jadi perlakukan sebagai tugas operasional: inventaris dulu, terapkan lewat siklus hidup normal, verifikasi dengan klien baru, dan siapkan pengembalian.

Mulai dari subnet yang sudah Anda miliki

Baca konfigurasi server saat ini dan alamat yang benar-benar dipegang klien. Perubahan pool hanya masuk akal terhadap garis dasar itu, dan garis dasar tidak selalu seperti yang disiratkan berkas, karena produk terkelola atau generator konfigurasi mungkin memiliki berkas yang Anda baca.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Pastikan topologi yang berlaku. Pada topologi subnet setiap klien mengambil satu alamat dari pool; tata letak net30 yang lebih tua memberi satu blok kecil per klien dan aritmetikanya sama sekali berbeda. Jika server masih di net30, halaman ini adalah panduan migrasi yang salah dan angka pool tidak akan berarti seperti yang Anda harapkan. Periksa baris itu sebelum menyalin aritmetika alamat dari tempat lain.

Catat alamat server itu sendiri, setiap penetapan tetap di direktori konfigurasi klien, dan alamat apa pun yang menjadi dasar rute atau aturan akses. Itulah alamat yang harus tetap di luar rentang dinamis. Mencatatnya lebih dulu adalah yang membuat rentang menjadi keputusan, bukan tebakan. Itu juga memberi pengembalian sesuatu yang konkret untuk dipulihkan.

Tambahkan nopool dan nyatakan rentangnya

Kata kunci pembantu menerima nopool, yang mempertahankan konfigurasi subnet dan menekan pool dinamis otomatis, seperti yang dijelaskan manual OpenVPN 2.6. Baris eksplisit ifconfig-pool kemudian memberikan rentang inklusif yang Anda maksud, dan netmask-nya cocok dengan subnet. Kedua baris berada dalam blok server yang sama, karena pool tanpa subnetnya tidak bermakna. Urutan di antara keduanya hanya penting untuk keterbacaan, sebab pembantu mengembangkan pasangan itu saat layanan dimulai.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Kedua batas bersifat inklusif, jadi contoh menawarkan tujuh puluh satu alamat. Jaga alamat server dan setiap penetapan tetap di luar rentang itu; penetapan tetap yang jatuh di dalam rentang dinamis menghasilkan tabrakan yang bergantung pada urutan koneksi, dan itu jenis terburuk untuk di-debug. Sisakan margin antara himpunan yang dicadangkan dan rentang bila penetapan tetap cenderung bertambah.

Ukuran rentang dan konkurensi adalah batas yang terpisah. Seratus alamat tidak berarti seratus klien bersamaan jika max-clients mengatakan sebaliknya, dan pool yang lebih besar dari batas konkurensi adalah normal, bukan pemborosan. Yang penting adalah kedua batas dipilih dengan sadar, bukan diwarisi dari bawaan.

Jaga penetapan tetap di luar rentang dinamis

Khusus klien ifconfig-push adalah mekanisme berbeda dari alokasi pool, dan harus memakai parameter yang sesuai dengan topologi aktif. Dalam mode subnet itu satu alamat dan netmask; membawa pasangan net30 karena muncul di contoh lama adalah kesalahan umum.

Riwayat alokasi adalah petunjuk, bukan otoritas. Berkas persist mengingat klien mana memegang alamat mana sehingga klien yang menyambung ulang cenderung menerima yang sama, dan berkas itu tidak mencadangkan alamat, tidak membebaskannya, dan tidak menggantikan penetapan tetap. Jika perangkat tertentu harus selalu memegang alamat tertentu, gunakan penetapan tetap alih-alih mengandalkan berkas persist.

Lalu periksa jalur yang bergantung pada alamat. Rute yang didorong ke klien, aturan firewall yang mengizinkan subnet, atau pemeriksaan pemantauan yang mengharapkan host tertentu semuanya bisa mengasumsikan rentang lama. Mengubah pool tanpa membacanya memindahkan kegagalan ke tempat yang tampak tidak berkaitan.

Terapkan lewat siklus hidup, lalu verifikasi

Terapkan perubahan sebagaimana layanan biasanya menerima konfigurasi, entah berkas langsung plus mulai ulang atau lapisan manajemen yang meregenerasi berkas. Suntingan manual pada berkas yang dihasilkan bertahan sampai generasi berikutnya, tidak lebih. Catat mekanisme mana yang memiliki berkas itu, karena operator berikutnya perlu tahu di mana melakukan perubahan yang sama. Lalu mulai ulang sekali dan baca log sebelum mengundang klien.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Sambungkan klien yang belum pernah tersambung dan pastikan alamatnya jatuh di dalam rentang yang dinyatakan dan di luar himpunan yang dicadangkan. Lalu pastikan jalur kembali: klien harus mencapai apa yang diizinkan kebijakan dan tidak lebih. Alamat yang sesuai rencana tetapi tidak punya rute yang berfungsi bukan perubahan yang berhasil.

Sambungkan ulang klien yang memegang alamat dari rentang lama. Klien itu harus menerima alamat dari rentang baru, dan status tingkat sesi apa pun yang terikat ke alamat lama harus hilang. Jika tetap memegang alamat lama, ada hal lain yang memberikannya dan pool bukan pemilik yang Anda kira.

Mengembalikan perubahan rentang

Simpan tiga baris sebelumnya dalam catatan perubahan Anda, bukan hanya berkas sebelumnya. Memulihkannya dan memulai ulang mengembalikan alokasi ke perilaku lama, dan klien yang menyambung ulang setelahnya akan menerima alamat darinya.

Dua peringatan termasuk dalam catatan. Klien yang sudah tersambung saat Anda mengembalikan tetap memegang alamat saat ini sampai menyambung ulang, jadi pengembalian tidak seketika di seluruh armada. Dan jika rentang lama tumpang tindih dengan penetapan tetap, memulihkannya memulihkan tabrakan juga; tumpang tindih itulah alasan perubahan, dan itu memerlukan perbaikan yang berbeda dari pengembalian.

Perubahan pool selesai ketika klien baru menerima alamat di dalam rentang, alamat yang dicadangkan tidak pernah diberikan, dan rute serta aturan yang memakai alamat itu masih berperilaku sebagaimana dimaksud. Apa pun yang kurang meninggalkan orang berikutnya untuk menemukan mana dari ketiganya yang tidak benar.