Catatan DDNS basi atau endpoint VPN rusak: cara membedakannya

Dari luar, nama host yang basi dan VPN yang rusak tampak identik. Klien me-resolve sebuah nama, nama itu menunjuk ke suatu tempat, dan koneksi berakhir karena waktu habis atau ditolak. Yang satu masalah pembaruan DNS dan yang lain masalah autentikasi atau penerusan, dan perbedaannya baru menjadi jelas ketika Anda membandingkan alamat yang dipublikasikan dengan alamat yang benar-benar dimiliki saluran Anda.

Dua kegagalan yang muncul dengan cara sama

Kegagalan pertama adalah catatan itu masih mencantumkan alamat WAN kemarin. Yang kedua adalah catatan itu benar dan terowongan menolak Anda karena alasannya sendiri. Keduanya menghasilkan pesan yang sama di klien, dan godaannya adalah mulai membuat ulang sertifikat.

Urutan penting di sini. Memeriksa DNS memakan satu menit dan bisa dibalik. Membuat ulang CA bukan keduanya.

Bandingkan alamatnya sebelum hal lain

Tanyakan kepada pemilik jaringan alamat mana yang dimiliki saluran saat ini, lalu tanyakan kepada DNS apa yang dipublikasikannya. dig +short vpn.example.com memberi jawaban yang akan diterima klien Anda, dan dig @1.1.1.1 vpn.example.com menunjukkan apakah resolver lain melihat hal berbeda. Jika keduanya tidak cocok, Anda sedang melihat perilaku cache dan bukan pembaru yang rusak.

Jawaban rekursif bisa tertinggal dari pembaruan sebesar TTL-nya, jadi simpan catatan otoritatif dan apa yang di-cache laptop Anda di kotak terpisah.

Apa sebenarnya kredensial pembaru itu

Perangkat DDNS lama sering melakukan autentikasi dengan kata sandi akun itu sendiri, dan itulah sebabnya mengubah kata sandi tersebut merusaknya secara diam-diam. Perangkat itu terus mencoba dengan nilai lama dan tidak melaporkan apa pun yang berguna. Panduan kata sandi perangkat dari No-IP mendokumentasikan persis masalah kompatibilitas ini pada perangkat keras lama, dan tanggapan yang masuk akal adalah kredensial pembaruan dengan cakupan terbatas, bukan kata sandi akun yang lebih lemah.

Mekanisme yang lebih baru menerbitkan token atau kunci pembaruan terpisah dengan siklus hidupnya sendiri. Itulah nilai yang harus dirotasi ke router, dan yang harus dicatat dalam inventaris kredensial Anda. Itu juga bukan nilai yang sebaiknya ditempel ke utas obrolan saat Anda men-debug.

Periksa status non-rahasia pembaru: waktu keberhasilan terakhir, kategori respons, dan nama host yang dianggapnya miliknya. Penolakan kredensial dan kegagalan konektivitas memerlukan perbaikan yang berbeda.

Apa yang tidak bisa dilakukan perbaikan DNS

Memperbaiki catatan tidak menciptakan keterjangkauan masuk. Jika saluran berada di belakang NAT tingkat operator, tidak ada nama host yang akan membuat koneksi masuk berfungsi. Itu juga tidak membuka aturan firewall atau meneruskan port. Dan itu tidak pernah menjadi alasan untuk menonaktifkan verifikasi server di klien, yang merupakan langkah yang diambil orang ketika mereka memutuskan sertifikatnya pasti masalahnya.

Sebaliknya, mengubah kata sandi VPN bukan perbaikan untuk DNS yang basi. Itu hanya menambahkan kegagalan kedua pada tiket yang sama.

Sambung ulang dan buktikan dari ujung ke ujung

Setelah catatan otoritatif benar, klien mungkin masih menyimpan pencarian lama. Gunakan sambung ulang atau penyegaran endpoint yang didukungnya dan beri waktu sejenak alih-alih menekan tombol sambung terus-menerus. Lalu buktikan jalurnya dalam empat langkah: resolve nama, konfirmasi alamat, periksa apakah pendengar dapat dijangkau, dan autentikasi. Empat hasil terpisah, empat jawaban terpisah.

Simpan pembaru dalam daftar periksa rotasi di samping akun VPN. Satu pemilik catatan yang dimaksudkan, kredensial yang valid, dan keberhasilan yang dapat diamati adalah yang mencegah versi berikutnya dari tiket ini.