Dari Access Server ke Community OpenVPN: apa yang harus dibangun ulang

Access Server dan Community OpenVPN berbicara protokol yang sama dan hampir tidak ada hal lain dengan cara yang sama. Handshake, negosiasi cipher, dan bidang data terowongan kompatibel, sehingga klien sering dapat terhubung ke keduanya tanpa mengedit profilnya. Yang berbeda adalah siapa yang memiliki konfigurasi: satu produk mengirimkan lapisan manajemen yang menulis dan menegakkan kebijakan, yang lain memberi Anda berkas konfigurasi dan sekumpulan kait dan mengharapkan Anda memutuskan.

Perbedaan itulah rencana migrasinya. Apa pun yang diputuskan produk lama atas nama Anda harus menjadi keputusan eksplisit di suatu tempat dalam penerapan baru.

Di mana kedua penerapan berhenti dapat dipertukarkan

Di Access Server, antarmuka administrasi web memiliki pengguna, grup, izin per pengguna, penerbitan sertifikat, dan bundel profil yang diunduh seseorang. Daemon di bawahnya dikonfigurasi oleh lapisan itu, sehingga layanan yang berjalan adalah hasil dari keadaan tersimpan yang jarang Anda sunting dengan tangan. Di Community OpenVPN, berkas konfigurasi adalah keadaannya: ia menamai pendengar, otoritas sertifikat, kait autentikasi, dan setiap opsi yang didorong, dan tidak ada yang menulis ulang untuk Anda. Mesin TLS yang sama karena itu berada di bawah dua model kepemilikan yang sangat berbeda.

Pemetaan singkat membuat celahnya konkret. Pengguna dan grup hanya ada di basis data lama sampai Anda membuatnya kembali. Bundel profil menjadi berkas konfigurasi plus sertifikat yang Anda distribusikan sendiri. Izin per pengguna menjadi direktif di dalam client-config-dir. Antarmuka admin menjadi proses apa pun yang Anda pilih untuk menerbitkan sertifikat dan menyunting berkas.

Tuliskan pemetaan itu sebelum menyentuh server. Setiap baris yang tidak dapat Anda isi adalah fitur yang akan Anda lepaskan, dan melepaskannya diam-diam adalah cara migrasi menjadi gangguan dua minggu kemudian.

Identitas tidak berpindah bersama berkas sertifikat

Sertifikat dari otoritas lama dapat terurai dengan benar di layanan baru dan tetap menjadi identitas yang salah, karena produk lama memasangkannya dengan keadaan akun yang tidak dapat dilihat yang baru. Putuskan lebih dulu apakah penerapan baru mengautentikasi hanya dengan sertifikat, dengan plugin yang menjangkau PAM atau RADIUS, atau dengan kombinasi, lalu periksa bahwa setiap opsi mempertahankan sifat yang Anda butuhkan. Sertifikat bersama tanpa identitas per pengguna adalah satu kredensial bagi semua yang memegangnya. Pencabutan juga harus bekerja sejak hari pertama, yang di Community OpenVPN berarti berkas CRL yang dirujuk crl-verify plus proses yang membuatnya ulang.

Rencanakan pendaftaran sebelum peralihan, bukan sesudahnya. Sertifikat baru, jalur pencabutan yang teruji, dan cara terdokumentasi untuk menonaktifkan satu orang adalah prasyarat, bukan pekerjaan lanjutan. Jika autentikasi multifaktor berasal dari integrasi produk lama, sebutkan penggantinya secara eksplisit, karena plugin yang tidak terpasang gagal tertutup pada saat terburuk.

Perutean dan resolusi nama mengikuti penulis konfigurasi

Rute, pengaturan DNS, dan perilaku terowongan penuh adalah opsi yang didorong di kedua produk, tetapi hanya satu yang menghitungnya untuk Anda. Di Community OpenVPN Anda menulis direktif push sendiri, memutuskan apakah redirect-gateway berada di server atau klien, dan memastikan penerusan serta NAT ada di host. Handshake yang selesai tidak memberi tahu Anda apa pun tentang penerusan, terjemahan alamat, atau rute yang benar-benar diterima klien.

Perilaku per klien membutuhkan client-config-dir plus berkas yang dinamai menurut common name sertifikat klien, dan pasangan situs ke situs membutuhkan entri iroute untuk prefiks di belakangnya. Jika penamaannya salah, opsi diabaikan tanpa kesalahan. Uji dengan satu klien non-produksi di kumpulan alamatnya sendiri, lalu baca alamat yang diberikan, rute yang diterimanya, dan pengaturan resolver yang ia dapat.

Atur peralihan agar layanan lama dapat kembali

Jalankan pendengar baru di port atau alamat lain, dan biarkan yang lama melayani lalu lintas selama Anda membuktikan penggantinya. Dua daemon pada satu soket bukan rencana pengembalian.

Pindahkan satu grup setiap kali, dengan sertifikat, kumpulan, dan rutenya sendiri, dan latih jalur kembali alih-alih menemukannya saat insiden. Pengembalian yang hanya berfungsi jika layanan baru dihentikan lebih dulu tetap pengembalian, tetapi harus diuji saat tidak ada yang terbakar.

Akhirnya, daftarkan fitur tanpa padanan langsung dan putuskan nasib masing-masing secara tertulis: unduhan profil mandiri, tanda izin per pengguna, antarmuka administrasi itu sendiri, pelaporan koneksi langsung. Menggantinya dengan proses manual terdokumentasi adalah jawaban yang sah. Membiarkan barisnya kosong bukan.

Pekerjaan selesai ketika pengguna yang tidak pernah melihat portal lama dapat mendaftar, terhubung, mencapai alamat internal yang dimaksud, dan dicabut dengan bersih. Semua sebelum titik itu adalah persiapan.