Baiki DNS WireGuard: 3 punca dan penyelesaian

Mengapa DNS gagal sebaik sahaja terowong WireGuard aktif

DNS melalui WireGuard gagal dalam tiga cara, dan setiap satunya mempunyai pembaikan tersendiri. Tiada nama dapat diselesaikan langsung, atau nama dapat diselesaikan tetapi pertanyaan keluar dari mesin anda di luar terowong, atau pengurus resolver milik klien sendiri menulis ganti tetapan beberapa saat selepas antara muka bermula. Hampir tiada masalah pada terowong itu sendiri. Masalahnya ialah baris yang memberitahu klien resolver yang perlu ditanya, serta penghalaan yang menentukan cara paket menuju ke resolver itu.

WireGuard memindahkan paket IP dan tidak mengetahui apa-apa tentang DNS (sistem nama domain, iaitu perkhidmatan yang menukar nama seperti example.com kepada alamat IP). Baris DNS = dalam blok klien [Interface] bukan tetapan WireGuard. Baris itu dibaca oleh wg-quick, iaitu pembungkus shell yang mengaktifkan antara muka, dan wg-quick kemudian mengubah konfigurasi resolver klien semasa terowong aktif serta memulihkannya pada wg-quick down. Oleh itu, setiap masalah di bawah ialah masalah penghalaan atau masalah wg-quick, bukan masalah kriptografi. Jika terowong itu sendiri belum dibina, mulakan dengan VPN WireGuard yang dihoskan sendiri pada VPS anda sendiri dan kembali ke halaman ini selepas itu.

Sahkan bahawa terowong berfungsi dengan baik sebelum mengubah DNS.

sudo wg show
ping -c 3 10.8.0.1
ping -c 3 1.1.1.1

wg show sepatutnya menyenaraikan peer dengan latest handshake yang terkini, dan kedua-dua ping sepatutnya menerima jawapan. Jika ping 1.1.1.1 tamat masa, anda menghadapi masalah pemajuan atau NAT (terjemahan alamat rangkaian), bukannya masalah DNS, dan sebarang jumlah konfigurasi resolver tidak akan membantu. Semua contoh di sini menggunakan 10.8.0.0/24 sebagai subnet terowong dan 10.8.0.1 sebagai alamat terowong pelayan. Gantikan nilai tersebut dengan nilai anda sendiri.

Kegagalan pertama: tiada apa-apa yang dapat diselesaikan kerana penyelesai tidak pernah menjawab

Gejalanya jelas. ping 1.1.1.1 berfungsi, manakala curl https://example.com mengembalikan ini:

curl: (6) Could not resolve host: example.com

Tanya penyelesai terowong secara terus daripada klien. dig disediakan oleh pakej dnsutils pada Ubuntu dan Debian.

dig +short @1.1.1.1 example.com
dig +short @10.8.0.1 example.com

Perintah pertama mengembalikan alamat, yang membuktikan paket boleh mencapai internet melalui terowong. Perintah kedua tidak mengembalikan apa-apa dan mencetak ;; communication timed out; no servers could be reached. Itulah keseluruhan diagnosisnya: klien anda diarahkan kepada 10.8.0.1, dan 10.8.0.1 tidak menjawab pada port UDP 53.

Dua punca boleh menyebabkannya. Sama ada tiada penyelesai yang berjalan pada pelayan, atau tembok api pelayan menggugurkan pertanyaan sebelum pertanyaan itu tiba. Periksa kedua-duanya pada pelayan.

sudo ss -ulnp | grep ':53'
sudo nft list ruleset

Penyelesai yang sedang berjalan dan terikat dengan betul akan memaparkan baris yang mengandungi 10.8.0.1:53 atau 0.0.0.0:53. Pada Ubuntu, perkara yang biasanya mengelirukan ialah 127.0.0.53:53: ini ialah pendengar stub systemd-resolved, yang mengikat alamat gelung balik dan sengaja tidak boleh dicapai dari mesin lain. Mengarahkan klien VPN kepada pelayan yang hanya mempunyai stub itu sebagai penyelesai menghasilkan tamat masa yang sama.

Penyelesaiannya ialah menggunakan penyelesai yang mendengar pada alamat terowong, serta satu peraturan tembok api yang membenarkan rakan terowong mencapainya.

sudo apt update && sudo apt install -y unbound
printf 'server:\n  interface: 10.8.0.1\n  access-control: 10.8.0.0/24 allow\n' \
  | sudo tee /etc/unbound/unbound.conf.d/wireguard.conf
sudo systemctl restart unbound
sudo ss -ulnp | grep '10.8.0.1:53'

Kemudian buka port itu untuk trafik terowong sahaja. Dengan nftables, tambahkan dua baris ini pada rantai input dalam /etc/nftables.conf dan muat semula dengan sudo systemctl reload nftables.

udp dport 53 iifname "wg0" accept
tcp dport 53 iifname "wg0" accept

Dengan ufw, sudo ufw allow in on wg0 to any port 53 melaksanakan tugas yang sama. Jangan sekali-kali buka port 53 kepada internet awam. Penyelesai rekursif yang terbuka akan ditemui oleh pengimbas dalam tempoh beberapa hari dan digunakan untuk menguatkan serangan penafian perkhidmatan, dan pembekal anda akan menyedari trafik itu sebelum anda menyedarinya.

Jalankan semula dig +short @10.8.0.1 example.com daripada klien. Alamat dalam output bermaksud laluan penyelesai berfungsi, jadi klien kini hanya perlu menggunakannya. Tambahkan baris itu pada blok [Interface] klien dan mulakan semula antara muka dengan sudo wg-quick down wg0 && sudo wg-quick up wg0.

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

Kegagalan kedua: DNS bocor kerana split tunnel tidak merutekan resolver

Masalah ini lebih serius kerana semuanya kelihatan berfungsi. Nama dapat diselesaikan, halaman dimuatkan, dan pertanyaan dihantar dalam teks jelas melalui rangkaian tempatan yang tidak ingin anda percayai.

Dua konfigurasi boleh menyebabkannya. Yang pertama ialah klien dengan AllowedIPs = 0.0.0.0/0, ::/0 tanpa baris DNS =. wg-quick memasang laluan lalai dalam jadual penghalaannya sendiri dan menambah peraturan dengan suppress_prefixlength 0. Ini sengaja mengekalkan laluan tempatan yang lebih khusus supaya mesin masih boleh mencapai pencetaknya. Resolver yang dipelajari klien melalui DHCP, biasanya penghala di 192.168.1.1, sepadan dengan salah satu laluan tempatan tersebut. Trafik anda melalui tunnel. Rangkaian tempatan masih menerima senarai penuh nama yang anda cari.

Yang kedua ialah split tunnel: AllowedIPs = 10.8.0.0/24 dengan DNS = 9.9.9.9. Oleh sebab 9.9.9.9 tidak berada dalam AllowedIPs, klien tidak mempunyai laluan kepadanya melalui tunnel. Oleh itu, pertanyaan dihantar melalui pautan tempatan seperti dalam kes pertama.

Buktikan resolver yang sebenarnya memberikan jawapan. whoami.akamai.net ialah nama ujian awam yang memberikan jawapan dengan alamat IP recursive resolver yang membuat pertanyaan. Dengan itu, anda boleh membandingkan jawapannya dengan alamat awam pelayan anda.

resolvectl status
dig +short whoami.akamai.net
sudo tcpdump -ni any -c 10 port 53

resolvectl status mencetak satu blok bagi setiap pautan. Jika blok bagi pautan ethernet atau wireless anda masih menunjukkan Current DNS Server: 192.168.1.1 manakala blok wg0 tidak menunjukkan apa-apa, itulah kebocoran tersebut. dig +short whoami.akamai.net yang mengembalikan alamat jalur lebar rumah anda, bukan alamat pelayan anda, mengesahkannya dari hujung jauh. Baris tcpdump ialah bukti yang menyelesaikan pertikaian: output yang sihat meletakkan setiap paket port 53 pada wg0, manakala kebocoran meletakkannya pada wlan0 atau enp3s0.

Penyelesaiannya mempunyai dua bahagian dan kedua-duanya diperlukan. Tetapkan DNS kepada alamat yang berada dalam tunnel, dan pastikan alamat tersebut berada dalam AllowedIPs.

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24, 10.20.0.0/16

10.8.0.1 berada dalam 10.8.0.0/24, jadi pertanyaan itu disulitkan dan dihantar kepada pelayan. Jika anda tetap mahu menggunakan resolver awam pada split tunnel, tambahkannya sebagai laluan hos: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Paket kemudiannya melalui tunnel, tetapi rangkaian tempatan masih boleh melihat bahawa anda memilih penyedia tersebut berdasarkan sesi terdahulu. Resolver yang anda kendalikan sendiri mengelakkan persoalan ini.

Penetapan resolver ialah salah satu perbezaan yang jelas antara WireGuard yang dibina secara manual dengan mesh yang diselaraskan. Ini merupakan sebahagian daripada pertukaran dalam perbandingan WireGuard dengan Tailscale. Menjalankan pelayan kawalan Headscale yang dihoskan sendiri memberikan penyelarasan itu tanpa menyerahkan bahan kunci anda kepada pihak ketiga.

Kegagalan tiga: resolvconf dan systemd-resolved bertelagah pada klien Linux

Klien macOS, Windows, iOS dan Android menggunakan DNS = melalui aplikasi rasmi dan biasanya tidak menimbulkan masalah. Masalah berlaku pada Linux kerana tetapan ini digunakan oleh skrip shell yang perlu menentukan pengurus resolver yang anda gunakan daripada beberapa pilihan.

Kegagalan pertama jelas kelihatan. sudo wg-quick up wg0 berhenti dengan:

resolvconf: command not found

wg-quick memanggil resolvconf, tetapi binari itu tidak dipasang. Pasang pelaksanaan yang berkomunikasi dengan systemd-resolved, kemudian aktifkan semula antara muka.

sudo apt install -y openresolv
sudo systemctl restart systemd-resolved
sudo wg-quick down wg0 && sudo wg-quick up wg0
resolvectl status wg0

Kegagalan kedua tidak jelas, dan inilah yang boleh mengambil masa berjam-jam untuk diselesaikan. Antara muka aktif, resolvectl status wg0 memaparkan DNS Servers: 10.8.0.1 dengan betul, tetapi carian masih dihantar kepada resolver lama. systemd-resolved menyimpan senarai resolver berasingan bagi setiap pautan dan memilih pautan untuk setiap pertanyaan. Jika tiada pautan ditandakan sebagai laluan lalai untuk nama, systemd-resolved terus menggunakan resolver pada pautan wayarles kerana pautan itu mempunyai domain carian, manakala pautan anda tidak.

Tetapkan resolver dan tuntut laluan lalai dalam langkah yang sama. %i dikembangkan kepada nama antara muka, jadi blok ini boleh digunakan tanpa perubahan pada mana-mana antara muka.

[Interface]
Address = 10.8.0.2/32
PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~.
PostDown = resolvectl revert %i

Padam baris DNS = apabila anda menggunakan PostUp dengan cara ini kerana jika tidak, dua mekanisme akan menulis keadaan resolver dan hanya satu daripadanya akan membersihkannya selepas itu. Argumen ~. ialah bahagian penting: argumen itu menandakan wg0 sebagai domain penghalaan bagi setiap nama, supaya systemd-resolved menghantar semua pertanyaan ke sana dan tidak memilih pautan bagi setiap pertanyaan. Sahkan tetapan itu.

resolvectl status wg0

Output yang sihat mengandungi DNS Servers: 10.8.0.1 dan Default Route: yes. Jika Default Route membaca no, bahagian resolvectl domain tidak dijalankan dan anda kembali kepada pemilihan pautan.

Satu lagi kes perlu disebut. Jika /etc/resolv.conf ialah fail sebenar dan bukannya pautan simbolik kepada /run/systemd/resolve/stub-resolv.conf, sesuatu yang lain memilikinya, biasanya NetworkManager atau runtime kontena. Jalankan ls -l /etc/resolv.conf sebelum menyahpepijat perkara lain kerana alat yang menulis semula fail itu pada setiap perubahan rangkaian akan membatalkan kerja anda pada waktu yang paling tidak sesuai.

Naik taraf: resolver penapisan anda sendiri melalui terowong

Setelah pertanyaan dapat melalui terowong dengan andal, resolver di hujung terowong menjadi titik kawalan. Menjalankan AdGuard Home di situ memberikan penapisan senarai sekatan dan log pertanyaan kepada setiap peranti yang disambungkan, tanpa perisian klien dan tanpa konfigurasi bagi setiap peranti. Skrip pemasangan rasmi, yang disemak pada Julai 2026, terdiri daripada satu baris.

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

Wizard persediaan mendengar pada port 3000 semasa kali pertama dijalankan. Aksesnya melalui terowong di http://10.8.0.1:3000 dan bukannya membuka port itu kepada umum. Dalam wizard, tetapkan alamat dengar DNS dan alamat dengar pentadbir kepada 10.8.0.1. Jika unbound daripada kegagalan pertama masih menggunakan alamat yang sama, hentikannya terlebih dahulu dengan sudo systemctl disable --now unbound kerana dua proses tidak boleh mengikat port UDP 53 pada satu alamat, lalu proses kedua keluar dengan listen udp 10.8.0.1:53: bind: address already in use.

Konfigurasi klien tidak perlu diubah jika sudah menyatakan DNS = 10.8.0.1. Log pertanyaan kini akan memaparkan setiap carian daripada setiap rakan setara. Ini ialah keputusan privasi yang sebenar, bukan manfaat percuma: anda memindahkan kepercayaan daripada penyedia internet kepada diri sendiri, dan anda sendiri perlu memastikan pelayan itu sentiasa ditampal. Pelayan yang terdedah kepada internet perlu mempunyai asas keselamatan terlebih dahulu, dan sepuluh minit pertama pada VPS baharu menerangkannya.

FAQ

Mengapakah terowong WireGuard saya bersambung tetapi nama tidak dapat diselesaikan?

Terowong membawa paket dan langsung tidak mengendalikan nama. Oleh itu, terowong yang berfungsi dengan carian yang gagal bermaksud penyelesai yang anda tetapkan tidak memberikan respons. Uji dengan dig +short @10.8.0.1 example.com daripada klien. Respons communication timed out bermaksud sama ada tiada penyelesai yang mendengar pada alamat terowong itu, biasanya kerana stub systemd-resolved hanya terikat pada 127.0.0.53, atau tembok api pelayan menggugurkan port UDP 53 yang tiba pada wg0. Betulkan pendengar terlebih dahulu, kemudian buka port itu untuk wg0 sahaja.

Bagaimanakah saya menyemak sama ada DNS saya bocor melalui WireGuard?

Jalankan sudo tcpdump -ni any -c 10 port 53 pada klien dan pantau lajur antara muka semasa anda melayari Internet. Setiap paket sepatutnya melalui wg0. Jika paket muncul pada antara muka wayarles atau ethernet anda, pertanyaan tersebut keluar dalam teks jelas. dig +short whoami.akamai.net memberikan pengesahan kedua kerana ia menjawab dengan alamat awam penyelesai rekursif yang membuat pertanyaan. Oleh itu, jawapan yang bukan alamat pelayan anda mengesahkan kebocoran itu.

Adakah saya memerlukan baris DNS = jika saya menggunakan terowong terpisah?

Ya, dan alamat penyelesai juga mesti berada dalam AllowedIPs. Jika tidak, klien tidak mempunyai laluan kepadanya. Dengan AllowedIPs = 10.8.0.0/24, penyelesai pada 10.8.0.1 diliputi dan pertanyaan itu disulitkan. Penyelesai awam seperti 9.9.9.9 tidak diliputi. Oleh itu, pertanyaan keluar melalui pautan tempatan walaupun baris DNS kelihatan betul.

Mengapakah resolvectl menunjukkan pelayan yang betul tetapi carian masih pergi ke tempat lain?

systemd-resolved menyimpan satu senarai penyelesai bagi setiap pautan dan memilih satu pautan untuk setiap pertanyaan. Oleh itu, entri yang betul pada wg0 diabaikan apabila pautan lain mempunyai laluan lalai untuk nama. Tambahkan PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. pada blok klien [Interface] dan keluarkan baris DNS =. resolvectl status wg0 sepatutnya kemudian melaporkan Default Route: yes.

Klien manakah yang perlu saya betulkan dahulu apabila beberapa klien rosak?

Betulkan satu klien Linux kerana hanya platform ini menunjukkan mekanismenya kepada anda. resolvectl status dan tcpdump memberitahu anda penyelesai yang memberikan respons dan antara muka yang membawa paket tersebut. Aplikasi telefon dan desktop menggunakan nilai DNS dan AllowedIPs yang sama tanpa mendedahkan butiran pelaksanaannya. Oleh itu, setelah klien Linux betul, anda hanya menyalin konfigurasi yang telah anda sahkan.