Bermigrasi dari VPN berbasis PPP tanpa menyalin asumsinya

Migrasi VPN selesai ketika pengguna, tujuan, resolusi nama, dan perilaku saat gagal semuanya masih benar, bukan ketika klien baru menampilkan ikon hijau. Penerapan lama berbasis PPP membawa asumsi yang tidak pernah dituliskan: satu rahasia bersama yang sekaligus menjadi satu-satunya pemeriksaan identitas, kumpulan alamat tetap yang ada di daftar izin firewall, dan sufiks DNS yang didorong server. Mengganti protokol tanpa menginventarisasi asumsi itu menghasilkan terowongan yang menyelesaikan handshake dan batas yang tidak ada. Urutan di bawah ini adalah urutan yang saya pakai, dan langkah terakhir adalah yang dilewati banyak tim.

Langkah 1: inventarisasikan apa yang disediakan koneksi lama

Inventaris ditulis, bukan diingat. Catat klien yang didukung, peran autentikasi, kumpulan alamat, jaringan yang dilindungi, kebutuhan DNS, dan izin layanan yang dibutuhkan setiap kelompok pengguna.

Untuk L2TP/IPsec, pisahkan kedua lapisan secara eksplisit. Identitas peer IPsec mengautentikasi mesin; PPP mengautentikasi pengguna, biasanya dengan CHAP atau MSCHAPv2.

Pada pemisahan itulah penerapan lama menyembunyikan asumsinya. Kunci pra-bagi yang dipakai bersama setiap klien mengautentikasi kelompok, bukan perangkat, dan sering kali itu satu-satunya hal yang pernah dirotasi. Jika akun PPP adalah kontrol nyata per pengguna, katakan begitu, karena penggantinya harus mereproduksi kontrol itu dengan sesuatu yang bukan string bersama. Catat juga alamat sumber tetap dan pengecualian jaringan lokal, karena itulah dependensi yang tidak didokumentasikan siapa pun sampai rusak.

Langkah 2: rancang penggantinya dengan sengaja

Memilih pengganti adalah pemetaan kebutuhan demi kebutuhan: protokol dan klien yang dipelihara dan didukung organisasi, dengan setiap kebutuhan identitas dan akses mendarat pada mekanisme nyata. Rahasia bersama tidak otomatis setara kunci atau sertifikat per perangkat, dan akun PPP per pengguna tidak setara sertifikat perangkat.

Koordinasi rentang alamat sebelum hal lain, karena kumpulan pengganti yang tumpang tindih dengan LAN rumah atau kantor menciptakan kegagalan yang tidak ada hubungannya dengan kekuatan sandi. Periksa kumpulan itu terhadap daftar yang sama yang Anda buat untuk layanan lama, ditambah apa yang diasumsikan klien baru secara bawaan. Pastikan perutean balik untuk jaringan yang dilindungi dan pastikan klien baru dapat mendorong atau mendokumentasikan sufiks DNS yang didorong yang lama. Dua hal itu menyebabkan lebih banyak tiket migrasi daripada perubahan protokol itu sendiri.

Langkah 3: terapkan bertahap dan verifikasi izin maupun penolakan

Terapkan dengan satu pengguna perwakilan dan satu aplikasi perwakilan. Sertakan resolusi DNS privat dalam pengujian, karena terowongan yang mencapai alamat tetapi tidak dapat menyelesaikan nama internal baru separuh termigrasi. Sertakan juga keadaan tidak tersedia yang diharapkan: apa yang harus terjadi saat terowongan putus, dan apakah klien memaksakannya.

Lalu uji tujuan yang seharusnya tetap ditolak. Aturan izin sementara yang lebar dapat membuat terowongan baru tampak sehat sambil diam-diam menghapus batas otorisasi yang ditegakkan layanan lama, dan tidak ada yang menyadarinya sampai audit. Bandingkan hasil izin dan penolakan berdampingan, dari klien yang sama, dalam sesi yang sama. Pertahankan layanan lama berjalan sampai kedua kolom cocok dengan rancangan.

Sebelum memindahkan akses administrator, pastikan Anda punya jalur pemulihan resmi yang tidak bergantung pada terowongan yang sedang Anda ubah.

Langkah 4: purnakan identitas lama

Memurnakan identitas lama dengan benar berarti mencabut pengguna dan kredensial perangkat yang usang melalui layanan yang memilikinya, lalu menghapus profil dan listener lama setelah tidak ada dependensi. Menghapus berkas lokal tidak mencabut salinan di tempat lain, dan listener lama yang masih menerima rahasia bersama lama adalah pintu tanpa pengawasan.

Poin itu layak diperlambat. Profil klien yang dinonaktifkan di laptop bukan kredensial yang dicabut; kredensial itu hidup di server dan tetap sah sampai server berhenti menerimanya. Cari salinan lain konfigurasi lama — perangkat uji, telepon yang terlupakan, pemasang yang disimpan seseorang — dan perlakukan pematian listener sebagai saat layanan lama benar-benar berakhir. Sampai saat itu, migrasi punya dua pintu depan.

Catatan penerimaan adalah inventaris dari langkah satu dengan satu kolom tambahan: apa yang dilakukan rancangan baru untuk setiap baris, dan bagaimana Anda memverifikasinya. Itu mengubah peningkatan protokol menjadi kebutuhan layanan dengan bukti.

Pertahankan hasilnya terikat pada kebutuhan layanan, bukan pada nama protokol, karena protokol modern dengan asumsi lama yang disalin ke dalamnya adalah risiko yang sama dengan pembingkaian lebih baik. RFC 3193 menjelaskan bagaimana L2TP diangkut di atas IPsec, yang merupakan pengingat berguna bahwa kedua lapisan itu selalu keputusan terpisah. Jika inventaris punya baris yang tidak bisa Anda jelaskan, berhenti dan cari tahu apa yang bergantung padanya. Migrasi selesai ketika daftarnya membosankan.