Adakah Anda Perlukan DNS Dinamik untuk Pelayan VPN Rumah?

Kebanyakan kegagalan VPN rumah yang orang tanyakan kepada saya bukan kegagalan DNS, namun mereka membeli langganan DNS dinamik dahulu. Sebelum mengkonfigurasi apa-apa, tentukan sama ada nama hos ialah bahagian yang benar-benar rosak. Pengemas kini menulis semula rekod apabila alamat yang diberikan ISP anda berubah; ia tidak boleh membuka port, menembusi NAT pembawa atau membuat sesi WireGuard yang hidup menyedari titik hujungnya telah berubah. Tiga syarat menentukan sama ada DNS dinamik ialah keseluruhan penyelesaian atau hanya satu baris daripadanya.

Keadaan satu: alamat anda benar-benar berubah

Alamat kediaman berubah atas sebab biasa: modem menyegerak semula selepas gangguan bekalan elektrik, ISP mengimbangi semula kolam, pajakan baharu tiba selepas gangguan panjang. Pada sesetengah talian ia juga jarang berubah, dan saya pernah melihat alamat yang sama bertahan setahun; pelan perniagaan selalunya termasuk alamat statik. Jika tiada apa berubah dalam dua belas bulan, satu rekod A yang anda sunting dengan tangan ialah satu daemon kurang untuk dihidupkan.

Ukur, jangan teka. Baca alamat WAN pada halaman status penghala, kemudian bandingkan dengan apa yang dilihat dunia luar. Jalankan ini dari mesin dalam LAN:

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

Jika kedua-dua nilai berbeza, ada sesuatu yang menterjemah di hadapan penghala anda dan tiada kemas kini nama hos akan membaikinya. Alamat dalam 100.64.0.0/10 ialah julat dikongsi untuk NAT gred pembawa, dan itulah sebab biasa nama yang dikemas kini dengan betul masih tamat masa dari luar.

Keadaan dua: klien mencari nama itu semula

TTL pendek ialah bahagian yang orang langkau. Penyelesai rekursif menghormati TTL rekod, tetapi tindanan klien menyimpan cache secara berasingan, dan terowong yang sudah berdiri tidak menyelesaikan apa-apa semula. Tetapkan rekod kepada 60-300 saat semasa menyahpepijat; itu memendekkan tetingkap apabila jawapan lapuk disampaikan, dan ia tidak memindahkan sesi yang bersambung.

OpenVPN menyelesaikan semula baris remote vpn.example.net 1194 setiap kali bersambung semula, dan resolv-retry infinite membuatnya terus mencuba semula dan bukannya keluar apabila carian gagal. Pada pelayan, float membenarkan sesi yang telah mantap mengikut rakan sebaya yang alamat sumbernya berubah. WireGuard lebih langsung: wg-quick up menyelesaikan Endpoint apabila konfigurasi digunakan, dan klien menyelesaikannya semula apabila membina semula terowong, jadi jabat tangan yang masih berjaya terhadap alamat lama terus berjaya sehingga ia berhenti.

Perbezaan itu membentuk pelan. Jika klien bersambung atas permintaan, perubahan alamat berharga satu sambungan semula. Jika mereka menahan sesi terbuka berhari-hari, jangkakan terowong mati pada jabat tangan seterusnya, dan buat klien mencuba semula dan bukannya menganggap ia kekal.

Keadaan tiga: laluan masuk masih terbuka

DNS dinamik hanya mengubah ke mana nama menunjuk dan tiada yang lain. Penerusan port pada penghala, peraturan tembok api pada hos VPN dan kebenaran ISP untuk paket masuk semuanya mesti wujud sebelum rekod itu bermakna. Perhatikan apa yang disasarkan penerusan: jika ia dipaku pada alamat WAN dan bukannya antara muka, perubahan alamat memutuskan penerusan secara senyap dan rekod yang dipersalahkan.

Uji dari luar. Telefon pada data selular dengan Wi-Fi dimatikan ialah ujian jujur termurah; komputer riba pada LAN yang sama bukan. Apabila nama menyelesaikan ke alamat awam anda dan penghala tiada gelung balik NAT, ujian dalaman gagal sedangkan rekod itu betul sepenuhnya, dan itu menghantar kebanyakan orang menyunting rekod yang tidak pernah salah.

Apa yang perlu dijalankan apabila ketiga-tiganya dipenuhi

ddclient ialah pengemas kini yang paling tidak mengejutkan untuk hos kecil. Konfigurasi minimum menerbitkan alamat yang dilihat penyedia, yang mengelakkan kesilapan NAT berganda:

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

Jalankannya dari pemasa systemd setiap beberapa minit dan bukannya gelung shell, dan log balasan penyedia dan bukannya menganggap kejayaan. Layani kelayakan seperti kunci, kerana ia menentukan ke mana setiap klien dihantar: gunakan token kemas kini terhad dan bukannya kata laluan akaun, simpan fail pada mod 0600 dan hantar kemas kini melalui HTTPS.

Pengesahan sebelum komited

Satu carian memberitahu anda apa yang dilihat seluruh dunia, dan ia mencetak TTL yang perlu anda tunggu selepas perubahan:

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

Bandingkan alamat itu dengan alamat WAN penghala. Jika sepadan, nama itu menjalankan tugasnya dan apa yang masih gagal ialah kebolehcapaian masuk, kunci atau klien yang belum menyelesaikan semula. Jika berbeza, pengemas kini menerbitkan antara muka yang salah, selalunya kerana ia berjalan pada hos VPN di belakang penghala dan bukannya pada penghala itu sendiri.

Simpan pengunduran yang mengambil masa seminit: catat alamat terakhir yang berfungsi dan TTL sebelumnya, supaya anda boleh menerbitkan kedua-duanya dengan tangan semasa penyedia mengalami petang yang buruk.

Apabila jawapannya tidak

Jika keadaan satu atau tiga gagal, keputusan yang berubah, bukan konfigurasi. Di sebalik NAT pembawa, pilihan praktikal anda ialah meminta alamat awam daripada ISP, memindahkan titik masuk ke VPS kecil dengan alamat stabil, atau menggunakan lapisan atas yang menyimpan pertemuannya sendiri. Jika alamat itu statik, langkau pengemas kini: satu rekod A, satu rekod AAAA jika anda menjalankan IPv6, penerusan port yang sama.

Jika alamat berubah semasa klien kekal bersambung, pembaikan jujur tinggal pada klien: logik sambung semula dan selang cubaan semula, bukan pengemas kini lebih pantas. Menambah penyedia kedua hanya menyembunyikan selang itu.

Sebelum meneruskan, sahkan empat perkara mengikut urutan:

• Alamat yang diterbitkan pengemas kini sepadan dengan alamat WAN penghala.
• TTL rekod cukup pendek supaya perubahan muncul dalam beberapa minit.
• Penerusan port terikat pada antara muka, bukan pada alamat tetap.
• Satu klien sebenar telah bersambung semula dan melepasi trafik sejak perubahan terakhir.

Jika keempat-empatnya dipenuhi, biarkan persediaan itu; kegagalan anda yang seterusnya ialah kunci atau peraturan tembok api dan bukan masalah penamaan. Jika ada yang gagal, betulkan baris itu sebelum menambah bahagian bergerak yang lain. RFC 2136 menerangkan mekanisme kemas kini itu sendiri, jika anda ingin melihat apa yang diletakkan daemon pada wayar.