VPN-nya pindah: kenapa klien OpenVPN Anda masih memanggil IP lama

Penyedia mengubah alamat publik Anda, Anda memperbarui catatan DNS dinamis, dan klien tetap tidak bisa terhubung. Dari luar terlihat seolah catatan itu belum menyebar. Biasanya catatan itu baik-baik saja dan klien memanggil alamat yang telah di-resolve sebelum pemindahan, karena terowongan yang berjalan dan profil tersimpan masing-masing punya anggapan sendiri tentang di mana server berada. Tiga lapisan harus sepakat, dan mereka diperbarui dengan jadwal berbeda.

Lihat apa yang dipanggil profil, bukan apa kata DNS

Buka koneksi yang benar-benar Anda pakai dan baca baris remote. Alamat numerik di sana tidak pernah mengikuti pembaruan nama host, sekalipun catatannya menjadi benar.

Lalu periksa apakah profil yang Anda edit adalah yang dimuat klien. Profil impor itu umum: seorang manajer mungkin mengambil salinan berbulan-bulan lalu dan menyimpan versinya sendiri, sehingga berkas di folder unduhan Anda dan entri di aplikasi bisa berbeda. Bandingkan titik akhir di detail koneksi klien itu sendiri sebelum Anda men-debug DNS sama sekali.

Dua berkas, satu titik akhir — itulah temuan yang biasa di sini.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Baca upaya koneksi berikutnya dari klien

Mulai ulang koneksi dengan pencatatan verbose dan baca baris yang menyebut alamat yang akan dihubungi. Nilai itulah yang penting, bukan yang di-resolve browser Anda.

Cache resolver masih bisa menyimpan jawaban sebelumnya, dan sebagian jaringan menyimpannya lebih lama daripada yang diminta TTL catatan. Tanyakan resolver yang benar-benar dipakai klien, bukan resolver publik yang Anda uji dari tempat lain.

Jika log menunjukkan alamat baru dan koneksi tetap gagal, masalahnya sudah berpindah: paket pergi ke suatu tempat dan tidak ada yang menjawab. Ini soal listener, firewall, atau penerusan port, dan letaknya di sisi server, bukan di jalur resolusi klien. Pisahkan kedua kegagalan itu, karena memperlakukan listener yang tak terjangkau sebagai masalah DNS membuat Anda dua kali melewati lingkaran yang sama.

Ketahui mulai ulang mana yang Anda lakukan

Tidak semua mulai ulang mempertahankan keadaan yang sama, karena itu perubahan alamat bisa berperilaku berbeda tergantung bagaimana proses didaur ulang. Mulai ulang lunak yang dipicu sinyal mempertahankan lebih banyak konteks sesi sebelumnya, sedangkan berhenti dan mulai penuh dimulai lagi dari konfigurasi. Jika Anda menguji apakah klien me-resolve ulang, Anda ingin jalur yang dimulai dari konfigurasi.

Pengaturan persistensi juga penting, karena dirancang untuk mempertahankan apa yang sudah diautentikasi, bukan untuk mengejar alamat baru.

Uji paling bersih adalah mulai baru dari profil yang dimaksud, lalu melihat baris log yang menyebut titik akhir. Apa pun yang Anda pelajari dari sesi yang dipertahankan sebagian adalah pernyataan tentang sesi itu.

Empat opsi dan tugasnya masing-masing

remote dengan nama host adalah pengaturan yang sama sekali memungkinkan resolusi ulang; alamat literal di baris itu menghalanginya. resolv-retry mengatur apa yang terjadi saat pencarian gagal, dan 2.6 sudah menjadikannya tanpa batas secara bawaan. Menambahkannya karena itu tidak mengubah apa pun, dan ia tidak pernah menjadwalkan pemeriksaan berkala untuk jawaban berbeda. Siapa pun yang mengatakan ia menyurvei alamat baru telah mencampur pemulihan dengan kesegaran.

persist-remote-ip soal kesinambungan, bukan kesegaran: ia memakai ulang titik akhir yang terakhir diautentikasi, di seluruh mulai ulang lunak yang didukungnya. Saat Anda menguji pemindahan, itu kebalikan dari yang Anda inginkan. Nonaktifkan untuk uji jika build Anda mengaktifkannya, lalu pulihkan setelah titik akhir baru terbukti. Jika dibiarkan aktif, sambungan kembali yang berhasil mungkin tidak memberi tahu apa pun tentang DNS.

float menerima peer terautentikasi yang alamatnya berubah di tengah sesi, dan hanya dalam susunan yang mendukungnya. Ia tidak menyegarkan DNS, dan tidak akan mengikuti perubahan penyedia dengan sendirinya. Perlakukan sebagai fitur ketahanan untuk peer yang berpindah, bukan sebagai mekanisme alamat dinamis untuk server.

Konfirmasi titik akhir baru sebelum menyalahkan klien

Dari luar jaringan Anda, periksa bahwa alamat baru punya listener di port yang dikonfigurasi dan penerusan penyedia mengarah ke sana. Catatan A yang benar untuk mesin tanpa port terbuka menghasilkan persis gejala yang orang-orang kaitkan dengan cache.

Lalu sambungkan ulang dan verifikasi dua hal: klien terautentikasi terhadap sertifikat server yang diharapkan, dan sesi mencapai sumber daya yang Anda maksud. Perubahan alamat tidak menurunkan persyaratan identitas, dan koneksi yang berhasil ke titik akhir yang salah lebih buruk daripada yang gagal. Panduan OpenVPN 2.6 mencantumkan keempat opsi dengan cakupannya masing-masing, dan itulah daftar periksa yang perlu disimpan di samping profil.

Pertahankan jalur di luar pita ke server sebelum Anda memulai ulang terowongan yang membawa akses administrasi Anda. Satu tindakan pencegahan itu mencegah sebagian besar insiden yang dihasilkan skenario ini.