VPN telah berpindah: mengapa klien OpenVPN anda masih mendail IP lama

Pembekal menukar alamat awam anda, anda mengemas kini rekod DNS dinamik, dan klien masih tidak dapat menyambung. Dari luar ia kelihatan seperti rekod itu tidak merebak. Kebanyakan masa rekod itu betul dan klien mendail alamat yang telah diselesaikannya sebelum perpindahan, kerana terowong yang berjalan dan profil yang disimpan masing-masing mempunyai tanggapan sendiri tentang di mana pelayan berada. Tiga lapisan mesti bersetuju, dan ia dikemas kini mengikut jadual yang berbeza.

Lihat apa yang didail profil, bukan apa kata DNS

Buka sambungan yang benar-benar anda gunakan dan baca baris remote. Alamat berangka di situ tidak pernah mengikut kemas kini nama hos, betapa betul pun rekod itu.

Kemudian semak sama ada profil yang anda sunting ialah yang dimuatkan oleh klien. Profil yang diimport adalah biasa: seorang pengurus mungkin mengambil salinan berbulan-bulan lalu dan menyimpan versinya sendiri, jadi fail dalam folder muat turun anda dan entri dalam aplikasi boleh berbeza. Bandingkan titik akhir dalam butiran sambungan klien itu sendiri sebelum anda menyahpepijat DNS langsung.

Dua fail, satu titik akhir — itulah penemuan biasa di sini.

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

Baca percubaan sambungan seterusnya klien

Mulakan semula sambungan dengan pengelogan terperinci dan baca baris yang menamakan alamat yang akan dihubungi. Nilai itulah yang penting, bukan yang diselesaikan oleh pelayar anda.

Cache penyelesai mungkin masih menyimpan jawapan sebelumnya, dan sesetengah rangkaian menyimpannya lebih lama daripada permintaan TTL rekod. Tanya penyelesai yang benar-benar digunakan oleh klien, bukan penyelesai awam yang anda uji dari tempat lain.

Jika log menunjukkan alamat baharu dan sambungan masih gagal, masalah telah berpindah: paket pergi ke suatu tempat dan tiada siapa menjawab. Ini soal pendengar, tembok api atau pemajuan port, dan ia terletak di sebelah pelayan, bukan di laluan penyelesaian klien. Asingkan kedua-dua kegagalan itu, kerana merawat pendengar yang tidak tercapai sebagai masalah DNS membuatkan anda dua kali melalui gelung yang sama.

Ketahui mula semula yang mana yang anda lakukan

Tidak semua mula semula mengekalkan keadaan yang sama, sebab itulah perubahan alamat boleh berkelakuan berbeza bergantung pada cara proses dikitar semula. Mula semula lembut yang dicetuskan oleh isyarat mengekalkan lebih banyak konteks sesi sebelumnya, manakala berhenti dan mula sepenuhnya bermula semula daripada konfigurasi. Jika anda menguji sama ada klien menyelesaikan semula, anda mahukan laluan yang bermula daripada konfigurasi.

Tetapan kegigihan juga penting, kerana ia direka untuk mengekalkan apa yang telah disahkan, bukan untuk mengejar alamat baharu.

Ujian paling bersih ialah permulaan baharu daripada profil yang dimaksudkan, diikuti dengan pandangan pada baris log yang menamakan titik akhir. Apa sahaja yang anda pelajari daripada sesi yang sebahagiannya dikekalkan ialah pernyataan tentang sesi itu.

Empat pilihan dan tugas berasingan mereka

remote dengan nama hos ialah tetapan yang sama sekali membolehkan penyelesaian semula; alamat literal pada baris itu menghalangnya. resolv-retry mengawal apa yang berlaku apabila carian gagal, dan 2.6 sudah menetapkannya kepada tak terhingga secara lalai. Menambahnya oleh itu tidak mengubah apa-apa, dan ia tidak pernah menjadualkan semakan berkala untuk jawapan yang berbeza. Sesiapa yang berkata ia meninjau alamat baharu telah mengelirukan pemulihan dengan kesegaran.

persist-remote-ip mengenai kesinambungan, bukan kesegaran: ia menggunakan semula titik akhir yang terakhir disahkan, merentasi mula semula lembut yang disokongnya. Semasa anda menguji perpindahan, itu adalah bertentangan dengan apa yang anda mahukan. Lumpuhkan untuk ujian jika binaan anda mengaktifkannya, kemudian pulihkan apabila titik akhir baharu terbukti. Jika dibiarkan aktif, sambungan semula yang berjaya mungkin tidak memberitahu anda apa-apa tentang DNS.

float menerima rakan setara yang disahkan yang alamatnya berubah di tengah sesi, dan hanya dalam susunan yang menyokongnya. Ia tidak menyegarkan DNS, dan ia tidak akan mengikut perubahan pembekal dengan sendirinya. Anggap ia sebagai ciri ketahanan untuk rakan setara yang merayau, bukan sebagai mekanisme alamat dinamik untuk pelayan.

Sahkan titik akhir baharu sebelum menyalahkan klien

Dari luar rangkaian anda, semak bahawa alamat baharu mempunyai pendengar pada port yang dikonfigurasi dan pemajuan pembekal menghala ke arahnya. Rekod A yang betul untuk mesin tanpa port terbuka menghasilkan tepat gejala yang orang kaitkan dengan cache.

Kemudian sambung semula dan sahkan dua perkara: klien disahkan terhadap sijil pelayan yang dijangkakan, dan sesi mencapai sumber yang anda maksudkan. Perubahan alamat tidak menurunkan keperluan identiti, dan sambungan yang berjaya ke titik akhir yang salah lebih buruk daripada yang gagal. Manual OpenVPN 2.6 menyenaraikan keempat-empat pilihan dengan skop masing-masing, dan itulah senarai semak yang perlu disimpan di sebelah profil.

Kekalkan laluan di luar jalur ke pelayan sebelum anda memulakan semula terowong yang membawa akses pentadbiran anda. Satu langkah berjaga-jaga itu menghalang kebanyakan insiden yang dihasilkan oleh senario ini.