ddclient menerbitkan jalan keluar VPN: betulkan sumber penemuan

Nama DNS anda kini menyelesaikan ke alamat penyedia VPN, dan log kemas kini kelihatan sepenuhnya sihat. Gabungan itu normal. Probe penemuan berasaskan web bertanya kepada perkhidmatan luar sumber mana yang dilihatnya, dan apabila permintaan keluar melalui VPN terowong penuh, jawapannya ialah jalan keluar VPN, bukan alamat WAN rumah anda. Pengemas kini telah menjalankan tugasnya; tugas itu dihalakan kepada pemerhatian yang salah.

Sahkan apa yang sepatutnya dicapai oleh nama itu

Nama awam untuk perkhidmatan rumah masuk memerlukan alamat yang melaluinya sambungan masuk yang diluluskan boleh mencapai perkhidmatan itu. Menerbitkan jalan keluar penyedia yang dikongsi tidak mengatur pemajuan masuk di sana, dan tiada konfigurasi DNS mencipta pemajuan itu. Tentukan perkara ini sebelum anda menyentuh pengemas kini, kerana ia menentukan alamat mana yang betul.

Nama peribadi untuk alamat terowong klien VPN ialah masalah lain dengan jawapan lain: ia tergolong dalam DNS peribadi, dan ia tidak memerlukan perkhidmatan penemuan awam sama sekali. Mencampurkan kedua-dua keperluan itulah cara konfigurasi yang berfungsi mula menerbitkan alamat yang tiada siapa minta.

Alamat antara muka juga perlu ditafsirkan. Alamat komputer riba di belakang penghala rumah bukan alamat WAN awam, dan malah alamat WAN penghala mungkin berada di belakang NAT gred pembawa, di mana menerbitkannya tidak dapat menghasilkan kebolehcapaian masuk.

Hasilkan semula nilai itu sebelum mengubah apa-apa

Perhatikan kedua-dua laluan secara berasingan. Dengan terowong naik, probe melaporkan jalan keluar; dengan terowong turun, atau dengan probe terikat pada antara muka fizikal, ia melaporkan alamat rumah: curl --interface eth0 https://ifconfig.me. Jika kedua-dua jawapan itu berbeza, anda telah menghasilkan semula kerosakan itu tanpa menyentuh pengemas kini.

Kemudian jalankan klien dalam mod yang memeriksa konfigurasi tanpa melakukan kemas kini, contohnya ddclient -verbose -noexec, dan baca kaedah penemuan mana yang dipilihnya. Output terperinci menamakan kaedah dan nilai yang diperoleh, dan itulah fakta yang anda perlukan sebelum menyunting apa-apa.

Halakan penemuan ke laluan yang dipilih

Jika nama itu mesti menerbitkan alamat WAN rumah, penemuan mesti memerhati alamat itu. Tiga pilihan berfungsi, dalam susunan keutamaan kasar: biarkan penghala menerbitkan melalui pengemas kininya sendiri yang disokong; gunakan penemuan status penghala ddclient terhadap halaman yang benar-benar disediakan oleh penghala; atau kekalkan probe web tetapi ikatkannya pada antara muka fizikal supaya ia keluar di luar terowong.

Untuk laluan status penghala, keluaran ddclient yang lebih baharu menggunakan keluarga pilihan usev4 dan fwv4, dengan corak langkau pilihan untuk teks halaman di sekelilingnya. Semak README untuk versi yang anda pasang, kerana keluaran lama menulis idea yang sama dengan use dan fw, dan nama pilihan yang disalin daripada keluaran yang salah gagal semasa permulaan.

Jika anda mengekalkan penemuan web, ingat bahawa penghalakan probe dan penghalakan panggilan API kemas kini ialah keputusan berasingan. Panggilan kemas kini menyampaikan rekod; probe menentukan nilai yang akan disampaikan.

Simpan rahsia dan versi dengan teratur

Kelayakan penghala dan token penyedia sepatutnya berada dalam fail konfigurasi yang dilindungi, bukan pada baris arahan yang berakhir dalam sejarah shell. Jejak terperinci boleh mengandungi kedua-duanya, jadi suntinglah sebelum menampalnya ke dalam tiket. Kaedah penemuan yang memerlukan pengikisan halaman penghala yang disahkan juga memerlukan anda memastikan kelayakan itu berfungsi merentas kemas kini firmware. Simpan dengan penjagaan yang sama seperti token penyedia.

ddclient README mendokumenkan pendekatan penemuan dan nama pilihan mereka. Jangan campurkan hasil IPv4 dan IPv6 dalam satu rekod, dan jangan andaikan pilihan yang ada dalam satu keluaran wujud dalam keluaran lain.

Sahkan nilainya, kemudian kebolehcapaian

Bandingkan alamat yang dicadangkan dengan titik akhir yang dimaksudkan sebelum membenarkan kemas kini langsung, kemudian periksa DNS berautoriti selepas satu kemas kini yang dibenarkan dan ambil kira cache penyelesai. TTL rendah memendekkan penantian; ia tidak menjadikan nilai yang salah itu betul.

Hanya selepas rekod itu betul anda patut menguji perkhidmatan masuk dari rangkaian bebas, dengan tembok api dan pemajuan yang diperlukan sudah diluluskan. Rekod A yang betul tidak membuktikan perkhidmatan yang boleh dicapai, dan pajakan VPN statik boleh memudahkan penamaan peribadi tanpa membaiki nama hos awam yang menunjuk ke WAN yang salah.