Pindah penyedia VPN: rencanakan nama host, bukan hanya IP

Catatan DNS Anda sudah benar, penggantinya sehat, tetapi beberapa klien tetap menghabiskan berjam-jam menghubungi alamat lama. Beberapa gagal seketika pada nama yang berhasil diselesaikan dan tidak pernah menjawab. Kedua hasil itu berasal dari satu celah: nama host mengubah apa yang dicari klien, bukan kapan ia mencarinya, dan bukan apa yang ia percayai saat jawaban tiba.

Gejalanya: catatan benar, terowongan basi

Profil yang menyimpan nama bukanlah klien yang terus menyelesaikannya. Sebagian besar menyelesaikannya sekali, saat konfigurasi diterapkan atau saat terowongan naik, lalu memakai ulang alamat itu sampai sesi berakhir. TTL panjang yang ditumpuk di atasnya adalah alasan peralihan harus direncanakan di sekitar koneksi ulang, bukan di sekitar penyuntingan DNS.

Tidak ada satu pun dari kedua perilaku itu yang cacat, dan itulah yang membuat gejalanya membingungkan. Klien bekerja dari jawaban yang diperolehnya sebelumnya, dan tidak ada apa pun di sisi server yang menunjukkan jawaban mana itu. Rencanakan koneksi ulang ke dalam jendela pemeliharaan dan beri tahu pengguna apa yang akan mereka lihat, atau habiskan jendela itu untuk menjawab tiket. Antrean laporan identik adalah hasil yang biasa.

Siapa yang mengendalikan nama, dan apa yang diverifikasi klien

Kendali atas zona menentukan seberapa cepat migrasi dapat bergerak. Simpan catatan di registrar yang dapat Anda masuki, dan tuliskan siapa lagi yang dapat mengubahnya.

Kepercayaan tidak mengikuti nama. Klien berbasis TLS dapat memeriksa identitas sertifikat atau nama yang disematkan, sedangkan WireGuard mengautentikasi kunci publik rekan dan sama sekali mengabaikan nama host. Perbedaan itulah yang menentukan apakah penyuntingan DNS cukup atau setiap profil memerlukan sidik jari baru. Perubahan catatan tidak boleh pernah mengotorisasi titik akhir yang tidak disetujui siapa pun.

Jauhkan akses administratif dan akses pemulihan dari nama klien publik. Kehilangan akun hosting tidak boleh juga membuat Anda kehilangan catatan yang mengalihkan klien. Simpan jalur pemulihan di tempat yang tidak bergantung pada penyedia yang Anda tinggalkan.

Kapan setiap klien membaca ulang nama

Waktu penyelesaian adalah properti tiap klien, jadi periksa implementasi yang benar-benar Anda kirimkan sebelum menjanjikan jendela peralihan. wg-quick menyelesaikan titik akhir saat antarmuka naik dan menyimpan alamat itu sampai terowongan dimulai ulang. Klien OpenVPN mencari nama saat terhubung, dan apakah ia melihat lagi saat koneksi ulang bergantung pada opsinya.

Klien seluler adalah kejutan yang biasa, karena mereka dapat mempertahankan alamat yang sudah diselesaikan melewati tidur atau perubahan jaringan. Terbitkan catatan A dan AAAA hanya jika penggantinya menjawab pada kedua keluarga. Alamat yang menjawab pada satu keluarga tidak membuktikan apa pun tentang yang lain, dan catatan AAAA yang mati menambahkan batas waktu pada setiap percobaan. Dokumentasikan perilaku penyelesaian untuk setiap klien yang Anda dukung, lalu uji pada perangkat yang benar-benar dipakai orang.

Koneksi ulang adalah tindakan pengguna pada sebagian besar klien, dan server tidak dapat memaksanya. Masukkan langkah itu ke catatan pemeliharaan, dengan satu baris tentang apa yang akan dilihat pengguna saat itu terjadi.

Beralihlah atas dasar bukti, lalu pensiunkan titik akhir lama

Sebelum peralihan, buktikan setiap lapisan pada pengganti: pendengar menjawab, firewall melewatkan port, rute kembali ke arah yang benar, nama terselesaikan ke alamat baru, dan identitas yang dikenal diterima. Pendengar yang menerima koneksi tidak sama dengan yang menyelesaikan jabat tangan, jadi ujilah jabat tangan, bukan port. Simpan daftar pencabutan saat ini di samping konfigurasi, karena cadangan yang dipulihkan membuat ulang daftar rekan seperti semula dan akan membuka kembali akses yang sudah Anda tutup. Catat identitas apa yang Anda gunakan untuk menguji, karena «ini berhasil» bukan bukti yang dapat diulang siapa pun.

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

Selama transisi, awasi upaya koneksi di kedua titik akhir untuk identitas yang sama. Klien yang masih mengautentikasi terhadap alamat lama adalah profil atau jawaban tersimpan yang tidak pernah berpindah. Pensiunkan titik akhir lama menurut rencana bertanggal, karena dua layanan yang menerima satu identitas meninggalkan dua pintu terbuka.

Uji peralihan adalah sesi aplikasi melalui titik akhir baru, bukan ping. Begitu sesi itu berhasil dan titik akhir lama tidak mencatat upaya resmi selama satu siklus koneksi ulang penuh, pemindahan selesai.