ddclient menerbitkan jalan keluar VPN: perbaiki sumber penemuan

Nama DNS Anda sekarang mengarah ke alamat penyedia VPN, dan log pembaruan tampak sepenuhnya sehat. Kombinasi itu normal. Probe penemuan berbasis web menanyakan ke layanan eksternal sumber mana yang dilihatnya, dan ketika permintaan keluar melalui VPN terowongan penuh, jawabannya adalah jalan keluar VPN, bukan alamat WAN rumah Anda. Pembaru menjalankan tugasnya; tugasnya diarahkan ke pengamatan yang salah.

Pastikan apa yang seharusnya dicapai nama itu

Nama publik untuk layanan rumah masuk memerlukan alamat yang melaluinya koneksi masuk yang disetujui dapat mencapai layanan itu. Menerbitkan jalan keluar penyedia bersama tidak mengatur penerusan masuk di sana, dan tidak ada konfigurasi DNS yang menciptakan penerusan itu. Putuskan ini sebelum Anda menyentuh pembaru, karena itu menentukan alamat mana yang benar.

Nama privat untuk alamat terowongan klien VPN adalah masalah lain dengan jawaban lain: itu milik DNS privat, dan sama sekali tidak memerlukan layanan penemuan publik. Mencampur kedua kebutuhan itulah cara konfigurasi yang berfungsi mulai menerbitkan alamat yang tidak diminta siapa pun.

Alamat antarmuka juga perlu ditafsirkan. Alamat laptop di belakang router rumah bukan alamat WAN publik, dan bahkan alamat WAN router dapat berada di belakang NAT tingkat operator, tempat menerbitkannya tidak dapat menghasilkan keterjangkauan masuk.

Reproduksi nilainya sebelum mengubah apa pun

Amati kedua jalur secara terpisah. Dengan terowongan aktif, probe melaporkan jalan keluar; dengan terowongan mati, atau dengan probe diikat ke antarmuka fisik, ia melaporkan alamat rumah: curl --interface eth0 https://ifconfig.me. Jika kedua jawaban itu berbeda, Anda telah mereproduksi kesalahan tanpa menyentuh pembaru.

Lalu jalankan klien dalam mode yang memeriksa konfigurasi tanpa melakukan pembaruan, misalnya ddclient -verbose -noexec, dan baca metode penemuan mana yang dipilihnya. Keluaran verbose menyebutkan metode dan nilai yang diperoleh, dan itulah fakta yang Anda butuhkan sebelum menyunting apa pun.

Arahkan penemuan ke jalur yang dipilih

Jika nama harus menerbitkan alamat WAN rumah, penemuan harus mengamati alamat itu. Tiga opsi berfungsi, dalam urutan preferensi kasar: biarkan router menerbitkan melalui pembaru bawaannya yang didukung; gunakan penemuan status router ddclient terhadap halaman yang benar-benar dilayani router; atau pertahankan probe web tetapi ikat ke antarmuka fisik agar keluar di luar terowongan.

Untuk jalur status router, rilis ddclient yang lebih baru menggunakan keluarga opsi usev4 dan fwv4, dengan pola lewati opsional untuk teks halaman di sekitarnya. Periksa README untuk versi yang Anda pasang, karena rilis lama menuliskan gagasan yang sama dengan use dan fw, dan nama opsi yang disalin dari rilis yang salah gagal saat mulai.

Jika Anda mempertahankan penemuan web, ingatlah bahwa merutekan probe dan merutekan panggilan API pembaruan adalah keputusan terpisah. Panggilan pembaruan mengirimkan catatan; probe menentukan nilai yang dikirim.

Jaga rahasia dan versi tetap rapi

Kredensial router dan token penyedia tempatnya di berkas konfigurasi yang dilindungi, bukan di baris perintah yang berakhir di riwayat shell. Jejak verbose dapat memuat keduanya, jadi suntinglah sebelum menempelkannya ke tiket. Metode penemuan yang memerlukan pengikisan halaman router terautentikasi juga menuntut Anda menjaga kredensial itu tetap berfungsi lintas pembaruan firmware. Simpan dengan kehati-hatian yang sama seperti token penyedia.

ddclient README mendokumentasikan pendekatan penemuan dan nama opsinya. Jangan mencampur hasil IPv4 dan IPv6 dalam satu catatan, dan jangan menganggap opsi yang ada di satu rilis ada di rilis lain.

Verifikasi nilainya, lalu keterjangkauannya

Bandingkan alamat yang diusulkan dengan titik akhir yang dimaksud sebelum mengizinkan pembaruan langsung, lalu periksa DNS otoritatif setelah satu pembaruan resmi dan perhitungkan cache resolver. TTL rendah mempersingkat penantian; itu tidak membuat nilai yang salah menjadi benar.

Hanya setelah catatan benar Anda sebaiknya menguji layanan masuk dari jaringan independen, dengan firewall dan penerusan yang diperlukan sudah disetujui. Catatan A yang benar tidak membuktikan layanan yang terjangkau, dan sewa VPN statis dapat menyederhanakan penamaan privat tanpa memperbaiki nama host publik yang menunjuk ke WAN yang salah.