Apakah Anda Perlu DNS Dinamis untuk Server VPN Rumahan?

Sebagian besar kegagalan VPN rumahan yang ditanyakan orang kepada saya bukan kegagalan DNS, tetapi mereka tetap membeli langganan DNS dinamis lebih dulu. Sebelum mengonfigurasi apa pun, putuskan apakah hostname adalah bagian yang benar-benar rusak. Updater menulis ulang catatan ketika alamat yang diberikan ISP Anda berpindah; ia tidak dapat membuka port, menembus NAT operator, atau membuat sesi WireGuard yang hidup menyadari bahwa endpoint-nya berubah. Tiga kondisi menentukan apakah DNS dinamis adalah seluruh solusinya atau hanya satu baris darinya.

Kondisi satu: alamat Anda benar-benar berpindah

Alamat rumahan berpindah karena alasan biasa: modem menyinkronkan ulang setelah listrik padam, ISP menyeimbangkan ulang kumpulan, sewa baru tiba setelah gangguan panjang. Di beberapa jalur alamat juga jarang berpindah, dan saya pernah melihat alamat yang sama bertahan setahun; paket bisnis sering menyertakan alamat statis. Jika tidak ada yang berubah dalam dua belas bulan, satu catatan A yang Anda sunting dengan tangan adalah satu daemon lebih sedikit untuk dijaga hidup.

Ukur, jangan menebak. Baca alamat WAN di halaman status router, lalu bandingkan dengan yang dilihat dunia luar. Jalankan ini dari mesin di LAN:

curl -fsS https://api.ipify.org; echo

Jika kedua nilai berbeda, ada sesuatu yang menerjemahkan di depan router Anda dan tidak ada pembaruan hostname yang memperbaikinya. Alamat di dalam 100.64.0.0/10 adalah rentang bersama untuk NAT tingkat operator, dan itulah alasan biasa sebuah nama yang diperbarui dengan benar tetap kehabisan waktu dari luar.

Kondisi dua: klien mencari nama itu lagi

TTL pendek adalah bagian yang dilewatkan orang. Resolver rekursif mematuhi TTL catatan, tetapi tumpukan klien menyimpan cache secara terpisah, dan terowongan yang sudah berdiri tidak menyelesaikan apa pun lagi. Setel catatan ke 60-300 detik saat Anda men-debug; itu memperpendek jendela ketika jawaban basi disajikan, dan itu tidak memindahkan sesi yang tersambung.

OpenVPN menyelesaikan ulang baris remote vpn.example.net 1194 setiap kali tersambung ulang, dan resolv-retry infinite membuatnya terus mencoba alih-alih keluar ketika pencarian gagal. Di server, float memungkinkan sesi yang sudah terbentuk mengikuti rekan yang alamat sumbernya berubah. WireGuard lebih langsung: wg-quick up menyelesaikan Endpoint saat konfigurasi diterapkan, dan klien menyelesaikannya lagi saat membangun ulang terowongan, jadi jabat tangan yang masih berhasil terhadap alamat lama terus berhasil sampai berhenti.

Perbedaan itu membentuk rencananya. Jika klien menyambung sesuai permintaan, perubahan alamat berbiaya satu penyambungan ulang. Jika mereka menahan sesi terbuka berhari-hari, perkirakan terowongan mati pada jabat tangan berikutnya, dan buat klien mencoba lagi alih-alih menganggapnya tetap hidup.

Kondisi tiga: jalur masuk masih terbuka

DNS dinamis hanya mengubah ke mana nama menunjuk dan tidak yang lain. Penerusan port di router, aturan firewall di host VPN, dan izin ISP untuk paket masuk semuanya harus ada sebelum catatan itu berarti. Perhatikan apa yang dituju penerusan: jika dipatok ke alamat WAN alih-alih antarmuka, perubahan alamat memutus penerusan secara diam-diam dan catatan yang disalahkan.

Uji dari luar. Ponsel dengan data seluler dan Wi-Fi mati adalah uji jujur termurah; laptop di LAN yang sama bukan. Ketika nama terselesaikan ke alamat publik Anda dan router tidak punya loopback NAT, uji dari dalam gagal padahal catatan sepenuhnya benar, dan itu mengirim sebagian besar orang menyunting catatan yang tidak pernah salah.

Apa yang dijalankan ketika ketiganya terpenuhi

ddclient adalah updater yang paling tidak mengejutkan untuk host kecil. Konfigurasi minimal menerbitkan alamat yang dilihat penyedia, yang menghindari kesalahan NAT ganda:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Jalankan dari timer systemd setiap beberapa menit alih-alih perulangan shell, dan catat balasan penyedia alih-alih menganggapnya sukses. Perlakukan kredensial seperti kunci, karena itu menentukan ke mana setiap klien dikirim: gunakan token pembaruan terbatas alih-alih kata sandi akun, simpan berkas pada mode 0600, dan kirim pembaruan lewat HTTPS.

Verifikasi sebelum berkomitmen

Satu pencarian memberi tahu apa yang dilihat seluruh dunia, dan mencetak TTL yang harus Anda tunggu setelah perubahan:

dig +noall +answer vpn.example.net @1.1.1.1

Bandingkan alamat itu dengan alamat WAN router. Jika cocok, nama itu menjalankan tugasnya dan yang masih gagal adalah keterjangkauan masuk, kunci, atau klien yang belum menyelesaikan ulang. Jika berbeda, updater menerbitkan antarmuka yang salah, sering karena ia berjalan di host VPN di belakang router alih-alih di router itu sendiri.

Pertahankan rollback yang memakan waktu satu menit: catat alamat terakhir yang berfungsi dan TTL sebelumnya, agar Anda dapat menerbitkan keduanya dengan tangan saat penyedia sedang sial.

Ketika jawabannya tidak

Jika kondisi satu atau tiga gagal, keputusannya yang berubah, bukan konfigurasinya. Di balik NAT operator, pilihan praktis Anda adalah meminta alamat publik ke ISP, memindahkan titik masuk ke VPS kecil dengan alamat stabil, atau memakai lapisan tambahan yang menyimpan pertemuannya sendiri. Jika alamatnya statis, lewati updater: satu catatan A, satu catatan AAAA jika Anda menjalankan IPv6, penerusan port yang sama.

Jika alamat berubah sementara klien tetap tersambung, perbaikan jujurnya ada di klien: logika penyambungan ulang dan interval percobaan ulang, bukan updater yang lebih cepat. Menambah penyedia kedua hanya menyembunyikan intervalnya.

Sebelum melanjutkan, pastikan empat hal secara berurutan:

• Alamat yang diterbitkan updater cocok dengan alamat WAN router.
• TTL catatan cukup pendek sehingga perubahan muncul dalam hitungan menit.
• Penerusan port terikat ke antarmuka, bukan ke alamat tetap.
• Satu klien nyata sudah tersambung ulang dan melewatkan lalu lintas sejak perubahan terakhir.

Jika keempatnya terpenuhi, biarkan penyiapannya; kegagalan berikutnya adalah kunci atau aturan firewall, bukan masalah penamaan. Jika ada yang gagal, perbaiki baris itu sebelum menambah bagian bergerak lain. RFC 2136 menjelaskan mekanisme pembaruan itu sendiri, jika Anda ingin melihat apa yang diletakkan daemon di kabel.