Tukar penyedia VPN: rancang nama hos, bukan hanya IP

Rekod DNS anda betul, penggantinya sihat, namun sesetengah klien menghabiskan berjam-jam mendail alamat lama. Beberapa gagal serta-merta pada nama yang diselesaikan dan tidak pernah menjawab. Kedua-dua hasil datang daripada satu jurang: nama hos mengubah apa yang dicari klien, bukan bila ia mencarinya, dan bukan apa yang dipercayainya apabila jawapan tiba.

Gejalanya: rekod betul, terowong usang

Profil yang menyimpan nama bukan klien yang terus menyelesaikannya. Kebanyakan menyelesaikannya sekali, semasa konfigurasi digunakan atau apabila terowong naik, kemudian menggunakan semula alamat itu sehingga sesi tamat. TTL panjang yang ditimbun di atasnya ialah sebab peralihan mesti dirancang sekitar sambungan semula dan bukan sekitar penyuntingan DNS.

Tiada satu pun daripada kedua-dua tingkah laku itu cacat, dan itulah yang membuatkan gejalanya mengelirukan. Klien bekerja dengan jawapan yang diperolehnya lebih awal, dan tiada apa-apa di sebelah pelayan menunjukkan jawapan mana itu. Rancang sambungan semula ke dalam tetingkap penyelenggaraan dan beritahu pengguna apa yang akan mereka lihat, atau habiskan tetingkap itu menjawab tiket. Barisan laporan yang serupa ialah hasil biasa.

Siapa mengawal nama, dan apa yang disahkan klien

Kawalan ke atas zon menentukan berapa pantas migrasi boleh bergerak. Simpan rekod di registrar yang boleh anda log masuk, dan tulis siapa lagi yang boleh mengubahnya.

Kepercayaan tidak mengikut nama. Klien berasaskan TLS boleh menyemak identiti sijil atau nama yang disematkan, manakala WireGuard mengesahkan kunci awam rakan dan mengabaikan nama hos sepenuhnya. Perbezaan itulah yang menentukan sama ada suntingan DNS mencukupi atau setiap profil memerlukan cap jari baharu. Perubahan rekod tidak sepatutnya sekali-kali membenarkan titik akhir yang tiada siapa luluskan.

Jauhkan akses pentadbiran dan akses pemulihan daripada nama klien awam. Kehilangan akaun hosting tidak sepatutnya turut merugikan anda rekod yang mengubah hala klien. Simpan laluan pemulihan di tempat yang tidak bergantung pada penyedia yang anda tinggalkan.

Bila setiap klien membaca semula nama

Masa penyelesaian ialah sifat setiap klien, jadi semak pelaksanaan yang benar-benar anda hantar sebelum menjanjikan tetingkap peralihan. wg-quick menyelesaikan titik akhir apabila antara muka naik dan menyimpan alamat itu sehingga terowong dimulakan semula. Klien OpenVPN mencari nama apabila ia bersambung, dan sama ada ia melihat semula semasa sambungan semula bergantung pada pilihannya.

Klien mudah alih ialah kejutan biasa, kerana ia boleh menyimpan alamat yang diselesaikan merentasi tidur atau perubahan rangkaian. Terbitkan rekod A dan AAAA hanya jika pengganti menjawab pada kedua-dua keluarga. Alamat yang menjawab pada satu keluarga tidak membuktikan apa-apa tentang yang lain, dan rekod AAAA mati menambah tamat masa pada setiap percubaan. Dokumentasikan tingkah laku penyelesaian untuk setiap klien yang anda sokong, kemudian uji pada peranti yang benar-benar digunakan orang.

Sambungan semula ialah tindakan pengguna dalam kebanyakan klien, dan pelayan tidak boleh memaksanya. Letakkan langkah itu dalam nota penyelenggaraan, dengan satu baris tentang apa yang akan dilihat pengguna apabila ia berlaku.

Beralih atas dasar bukti, kemudian hentikan titik akhir lama

Sebelum peralihan, buktikan setiap lapisan pada pengganti: pendengar menjawab, tembok api melepaskan port, laluan kembali ke arah yang betul, nama diselesaikan ke alamat baharu, dan identiti yang dikenali diterima. Pendengar yang menerima sambungan tidak sama dengan yang menyelesaikan jabat tangan, jadi uji jabat tangan dan bukan port. Simpan senarai pembatalan semasa di sebelah konfigurasi, kerana sandaran yang dipulihkan mencipta semula senarai rakan seperti asalnya dan akan membuka semula akses yang sudah anda tutup. Catat identiti yang anda gunakan untuk menguji, kerana «ia berfungsi» bukan bukti yang boleh diulang oleh sesiapa.

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

Semasa peralihan, perhatikan percubaan sambungan pada kedua-dua titik akhir untuk identiti yang sama. Klien yang masih mengesahkan diri terhadap alamat lama ialah profil atau jawapan cache yang tidak pernah berpindah. Hentikan titik akhir lama mengikut pelan bertarikh, kerana dua perkhidmatan yang menerima satu identiti meninggalkan dua pintu terbuka.

Ujian peralihan ialah sesi aplikasi melalui titik akhir baharu, bukan ping. Sebaik sahaja sesi itu berfungsi dan titik akhir lama tidak merekodkan sebarang percubaan dibenarkan sepanjang kitaran sambungan semula penuh, pemindahan selesai.