Cara Selesaikan Masalah DNS pada WireGuard

Mengapa DNS terputus sebaik sahaja tunnel WireGuard diaktifkan

DNS melalui WireGuard gagal dalam tiga cara, dan setiap satunya mempunyai penyelesaian tersendiri. Tiada apa-apa yang dapat diselesaikan (resolve), atau nama berjaya diselesaikan tetapi pertanyaan keluar dari mesin anda di luar tunnel, atau pengurus resolver klien sendiri menulis ganti tetapan tersebut beberapa saat selepas antara muka bermula. Masalahnya hampir tidak pernah berpunca daripada tunnel itu sendiri. Masalahnya terletak pada satu baris yang memberitahu klien resolver mana yang perlu ditanya, dan penghalaan (routing) yang menentukan bagaimana paket ke resolver tersebut bergerak.

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

Pastikan tunnel berada dalam keadaan baik sebelum anda menyentuh DNS sama sekali.

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 harus mendapat jawapan. Jika ping 1.1.1.1 tamat masa (timeout), anda mempunyai masalah penghalaan atau NAT (network address translation) dan bukannya masalah DNS, dan sebanyak mana pun konfigurasi resolver tidak akan membantu. Setiap contoh di sini menggunakan 10.8.0.0/24 sebagai subnet tunnel dan 10.8.0.1 sebagai alamat tunnel pelayan. Gantikan dengan maklumat anda sendiri.

Kegagalan satu: tiada apa-apa yang diselesaikan, kerana resolver tidak pernah menjawab

Simptomnya adalah tepat. ping 1.1.1.1 berfungsi, dan curl https://example.com mengembalikan ini:

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

Tanya resolver terowong secara terus daripada klien. dig datang daripada 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 sampai ke internet melalui terowong. Perintah kedua tidak mengembalikan apa-apa dan mencetak ;; communication timed out; no servers could be reached. Itulah diagnosis keseluruhannya: klien anda dihalakan ke 10.8.0.1, dan 10.8.0.1 tidak menjawab pada port UDP 53.

Dua punca menghasilkannya. Sama ada tiada resolver yang berjalan pada pelayan, atau firewall pelayan menggugurkan pertanyaan tersebut sebelum ia sampai. Semak kedua-duanya pada pelayan.

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

Resolver yang sedang berjalan dan terikat dengan betul akan menunjukkan baris dengan 10.8.0.1:53 atau 0.0.0.0:53. Pada Ubuntu, kejutan biasanya adalah 127.0.0.53:53: itu adalah pendengar stub systemd-resolved, yang mengikat alamat loopback dan sengaja tidak boleh dicapai daripada mesin lain. Menghalakan klien VPN ke pelayan yang resolver tunggalnya adalah stub tersebut akan menghasilkan timeout ini.

Penyelesaiannya ialah resolver yang mendengar pada alamat terowong, ditambah satu peraturan firewall yang membenarkan rakan setara (peers) 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 untuk trafik terowong sahaja. Dengan nftables, tambahkan dua baris ini ke dalam chain 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 melakukan tugas yang sama. Jangan sekali-kali membuka port 53 kepada internet awam. Resolver rekursif yang terbuka akan ditemui oleh pengimbas dalam masa beberapa hari dan digunakan untuk menguatkan serangan penafian perkhidmatan (denial of service), dan penyedia anda akan menyedari trafik tersebut sebelum anda.

Jalankan semula dig +short @10.8.0.1 example.com daripada klien. Alamat dalam output bermakna laluan resolver berfungsi, jadi klien kini hanya perlu menggunakannya. Tambahkan baris tersebut ke dalam blok [Interface] klien dan mulakan semula antaramuka 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 dua: Kebocoran DNS, kerana split tunnel tidak menghalakan resolver

Ini lebih buruk, kerana semuanya kelihatan berfungsi. Nama diselesaikan, halaman dimuatkan, dan pertanyaan bergerak dalam teks jelas merentasi rangkaian tempatan yang anda tidak mahu percayai.

Dua konfigurasi menyebabkannya. Yang pertama ialah klien dengan AllowedIPs = 0.0.0.0/0, ::/0 dan tiada baris DNS =. wg-quick memasang laluan lalai dalam jadual penghalaannya sendiri dan menambah peraturan dengan suppress_prefixlength 0, yang mengekalkan laluan tempatan yang lebih spesifik supaya mesin masih boleh mencapai pencetaknya. Resolver yang dipelajari oleh 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. Kerana 9.9.9.9 tidak berada di dalam AllowedIPs, klien tidak mempunyai laluan kepadanya melalui tunnel, jadi pertanyaan keluar melalui pautan tempatan seperti dalam kes pertama.

Buktikan resolver mana yang sebenarnya menjawab. whoami.akamai.net ialah nama ujian awam yang menjawab dengan alamat IP resolver rekursif yang bertanya, supaya 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 untuk pautan ethernet atau wayarles anda masih menunjukkan Current DNS Server: 192.168.1.1 manakala blok wg0 tidak menunjukkan apa-apa, itulah kebocorannya. dig +short whoami.akamai.net yang mengembalikan alamat jalur lebar rumah anda dan bukannya alamat pelayan anda mengesahkannya dari hujung sana. Baris tcpdump ialah bukti yang menyelesaikan pertikaian: output yang sihat meletakkan setiap paket port 53 pada wg0, dan kebocoran meletakkannya pada wlan0 atau enp3s0.

Pembaikannya mempunyai dua bahagian dan kedua-duanya diperlukan. Tetapkan DNS kepada alamat yang berada di dalam tunnel, dan pastikan alamat tersebut berada di 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 di dalam 10.8.0.0/24, jadi pertanyaan disulitkan dan dihantar ke pelayan. Jika anda berkeras untuk menggunakan resolver awam pada split tunnel, tambahkannya sebagai laluan hos: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Paket kemudiannya di-tunnel, walaupun rangkaian tempatan masih boleh melihat bahawa anda memilih penyedia tersebut daripada sesi sebelumnya. Resolver yang anda jalankan sendiri mengelakkan persoalan ini.

Penetapan resolver ialah salah satu perbezaan ketara antara WireGuard yang dibina secara manual dengan mesh yang diselaraskan. Perbezaan ini merupakan sebahagian daripada pertimbangan dalam perbandingan WireGuard dengan Tailscale. Menjalankan pelayan kawalan Headscale yang dihoskan sendiri memberikan penyelarasan itu tanpa menyerahkan bahan kunci anda kepada pihak ketiga. Jika frasa terakhir itu yang membimbangkan anda, ambil perhatian bahawa Tailscale tidak pernah menyimpan kunci yang menyulitkan trafik anda. Persoalan yang lebih penting ialah perkara yang boleh ditambahkan pada rangkaian anda oleh pelayan penyelarasan yang telah diceroboh atau akaun identiti yang dicuri.

Kegagalan tiga: konflik antara resolvconf dan systemd-resolved pada klien Linux

Klien macOS, Windows, iOS dan Android menggunakan DNS = melalui aplikasi rasmi dan jarang menimbulkan masalah. Pada Linux, tetapan ini digunakan melalui skrip shell yang perlu meneka pengurus resolver mana yang anda gunakan.

Kegagalan pertama adalah nyata. sudo wg-quick up wg0 terhenti dengan:

resolvconf: command not found

wg-quick memanggil resolvconf, dan binari tersebut tidak dipasang. Pasang implementasi yang berhubung dengan systemd-resolved, kemudian naikkan semula antaramuka tersebut.

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 adalah senyap, dan ia merupakan masalah yang memakan masa. Antaramuka berjaya naik, resolvectl status wg0 menunjukkan DNS Servers: 10.8.0.1 dengan betul, namun carian masih pergi ke resolver lama. systemd-resolved mengekalkan senarai resolver yang berasingan bagi setiap pautan dan memilih pautan untuk setiap pertanyaan. Kecuali satu pautan ditandakan sebagai laluan lalai (default route) untuk nama, ia akan terus menggunakan resolver pautan wayarles, kerana pautan tersebut membawa domain carian manakala pautan anda tidak.

Tetapkan resolver dan tuntut laluan lalai dalam langkah yang sama. %i berkembang kepada nama antaramuka, jadi blok ini berfungsi tanpa perubahan pada mana-mana antaramuka.

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

Padamkan baris DNS = apabila anda menggunakan PostUp dengan cara ini, kerana jika tidak, dua mekanisme akan menulis status resolver dan hanya satu daripadanya yang akan melakukan pembersihan selepas itu. Argumen ~. adalah bahagian yang penting: ia menandakan wg0 sebagai domain penghalaan untuk setiap nama, supaya systemd-resolved menghantar semua pertanyaan ke sana dan bukannya memilih pautan bagi setiap pertanyaan. Sahkan perkara ini.

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 yang perlu dinyatakan. Jika /etc/resolv.conf merupakan fail sebenar dan bukannya symlink kepada /run/systemd/resolve/stub-resolv.conf, sesuatu yang lain memilikinya, biasanya NetworkManager atau runtime kontena. Jalankan ls -l /etc/resolv.conf sebelum anda menyahpepijat perkara lain, kerana alat yang menulis semula fail tersebut pada setiap perubahan rangkaian akan membatalkan kerja anda pada saat yang paling tidak diingini.

Naik taraf: resolver penapisan anda sendiri melalui tunnel

Apabila pertanyaan bergerak dengan lancar melalui tunnel, resolver di hujung sana menjadi titik kawalan. Menjalankan AdGuard Home di sana memberikan penapisan senarai sekat dan log pertanyaan kepada setiap peranti yang bersambung, tanpa memerlukan perisian klien atau konfigurasi setiap peranti. Skrip pemasangan rasmi, yang disemak pada Julai 2026, hanyalah satu baris arahan.

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. Capai wizard tersebut melalui tunnel di http://10.8.0.1:3000 dan bukannya membuka port tersebut kepada umum, dan dalam wizard tersebut tetapkan alamat pendengar DNS serta alamat pendengar admin kepada 10.8.0.1. Jika unbound daripada kegagalan satu masih memegang alamat yang sama, hentikannya dahulu dengan sudo systemctl disable --now unbound, kerana dua proses tidak boleh mengikat port UDP 53 pada satu alamat dan proses kedua akan keluar dengan listen udp 10.8.0.1:53: bind: address already in use.

Konfigurasi klien tidak perlu diubah jika ia sudah menyatakan DNS = 10.8.0.1. Log pertanyaan kini akan menunjukkan setiap carian daripada setiap peer, yang merupakan keputusan privasi sebenar dan bukannya keuntungan percuma: anda memindahkan kepercayaan daripada pembekal internet anda kepada diri sendiri, dan anda adalah pihak yang perlu memastikan kotak tersebut sentiasa dikemas kini dengan patch. Pelayan yang terdedah kepada internet memerlukan asas keselamatan dipasang terlebih dahulu, dan sepuluh minit pertama pada VPS baharu merangkumi perkara tersebut.

FAQ

Mengapa terowong WireGuard saya bersambung tetapi nama tidak dapat diselesaikan (resolve)?

Terowong hanya membawa paket dan tidak mengendalikan nama, jadi terowong yang berfungsi dengan carian yang gagal bermakna resolver yang anda tuju tidak memberikan respons. Uji dengan dig +short @10.8.0.1 example.com daripada klien. Balasan communication timed out bermakna tiada resolver yang mendengar pada alamat terowong tersebut, selalunya kerana stub systemd-resolved hanya terikat pada 127.0.0.53, atau firewall pelayan menggugurkan port UDP 53 yang tiba pada wg0. Betulkan pendengar (listener) dahulu, kemudian buka port tersebut untuk wg0 sahaja.

Bagaimanakah cara saya menyemak sama ada DNS saya bocor melalui WireGuard?

Jalankan sudo tcpdump -ni any -c 10 port 53 pada klien dan perhatikan lajur antara muka (interface) semasa anda melayari internet. Setiap paket sepatutnya berada pada wg0. Jika ia muncul pada antara muka wayarles atau ethernet anda, pertanyaan tersebut keluar dalam bentuk teks jelas (cleartext). dig +short whoami.akamai.net memberikan pendapat kedua, kerana ia menjawab dengan alamat awam bagi mana-mana resolver rekursif yang bertanya, jadi jawapan yang bukan alamat pelayan anda mengesahkan kebocoran tersebut.

Adakah saya memerlukan baris DNS = jika saya menggunakan split tunnel?

Ya, dan alamat resolver juga mestilah berada di dalam AllowedIPs atau klien tidak mempunyai laluan (route) ke arahnya. Dengan AllowedIPs = 10.8.0.0/24, resolver pada 10.8.0.1 dilindungi dan pertanyaan tersebut disulitkan. Resolver awam seperti 9.9.9.9 tidak dilindungi, jadi pertanyaan tersebut keluar melalui pautan tempatan walaupun baris DNS kelihatan betul.

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

systemd-resolved menyimpan satu senarai resolver bagi setiap pautan dan memilih pautan bagi setiap pertanyaan, jadi entri yang betul pada wg0 diabaikan sementara pautan lain memegang laluan lalai (default route) untuk nama. Tambahkan PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. ke dalam blok [Interface] klien dan buang baris DNS =. resolvectl status wg0 sepatutnya melaporkan Default Route: yes selepas itu.

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

Baiki satu klien Linux, kerana ia merupakan satu-satunya platform yang menunjukkan mekanisme tersebut kepada anda. resolvectl status dan tcpdump memberitahu anda resolver mana yang menjawab dan antara muka mana yang membawa paket tersebut. Aplikasi telefon dan desktop menggunakan nilai DNS dan AllowedIPs yang sama tanpa sistem dalaman yang boleh dilihat, jadi sebaik sahaja klien Linux betul, anda hanya menyalin konfigurasi yang telah anda buktikan keberkesanannya.