Ayusin ang DNS sa WireGuard: 3 karaniwang problema

Bakit biglang nasisira ang DNS kapag umaandar ang WireGuard tunnel

Nabibigo ang DNS sa WireGuard sa 3 paraan, at may hiwalay na solusyon ang bawat isa. Maaaring walang anumang nare-resolve, maaaring nareresolve ang mga pangalan pero lumalabas sa machine mo ang mga query sa labas ng tunnel, o maaaring ino-overwrite ng sariling resolver manager ng client ang setting ilang segundo pagkatapos mag-start ang interface. Halos hindi kailanman ang tunnel ang problema. Ang problema ay ang linyang nagsasabi sa client kung aling resolver ang tatanungin, at ang routing na nagtatakda kung paano bibiyahe ang mga packet papunta sa resolver na iyon.

Ang WireGuard ay naglilipat ng mga IP packet at walang alam tungkol sa DNS (domain name system, ang serbisyong nagta-translate ng mga pangalan gaya ng example.com tungo sa mga IP address). Ang linyang DNS = sa isang client [Interface] block ay hindi setting ng WireGuard. Binabasa ito ng wg-quick, ang shell wrapper na nag-a-activate sa interface, at pagkatapos ay ine-edit ng wg-quick ang resolver configuration ng client habang aktibo ang tunnel at nire-restore ito sa wg-quick down. Kaya ang bawat problemang nasa ibaba ay problema sa routing o problema sa wg-quick, at hindi kailanman problema sa cryptography. Kung hindi pa nagagawa ang tunnel, magsimula sa isang self-hosted WireGuard VPN sa sarili mong VPS at bumalik sa page na ito pagkatapos.

Tiyaking maayos ang tunnel bago mo galawin ang DNS.

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

Dapat ilista ng wg show ang peer na may kamakailang latest handshake, at dapat sumagot ang parehong ping. Kung nagti-time out ang ping 1.1.1.1, forwarding o NAT (network address translation) problem ito at hindi DNS problem, kaya walang maitutulong ang anumang resolver config. Sa bawat halimbawa rito, ginagamit ang 10.8.0.0/24 bilang tunnel subnet at ang 10.8.0.1 bilang tunnel address ng server. Palitan ang mga ito ng sarili mong value.

Kabiguan one: walang nagre-resolve dahil hindi sumasagot ang resolver

Tiyak ang sintomas. Gumagana ang ping 1.1.1.1, at ibinabalik ng curl https://example.com ang:

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

Direktang magtanong sa tunnel resolver mula sa client. Ang dig ay mula sa dnsutils package sa Ubuntu at Debian.

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

Nagbabalik ng address ang unang command. Pinatutunayan nito na nakakarating ang mga packet sa internet sa pamamagitan ng tunnel. Walang ibinabalik ang ikalawa at nagpi-print ito ng ;; communication timed out; no servers could be reached. Iyan ang buong diagnosis: nakaturo ang client mo sa 10.8.0.1, at hindi sumasagot ang 10.8.0.1 sa UDP port 53.

Dalawang sanhi ang posibleng dahilan. Maaaring walang resolver na tumatakbo sa server, o ibinabagsak ng server firewall ang query bago ito makarating. Suriin ang dalawa sa server.

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

Ang resolver na tumatakbo at tama ang pagkaka-bind ay nagpapakita ng linyang may 10.8.0.1:53 o 0.0.0.0:53. Sa Ubuntu, karaniwang nakalilito ang 127.0.0.53:53: ito ang systemd-resolved stub listener, na nagba-bind sa loopback address at sadyang hindi naaabot mula sa ibang machine. Kapag itinuro ang VPN client sa server na ang tanging resolver ay ang stub na ito, eksaktong timeout na ito ang nangyayari.

Ang ayos ay isang resolver na nakikinig sa tunnel address, kasama ang isang firewall rule na nagpapahintulot sa mga peer na maabot ito.

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'

Pagkatapos, buksan ang port para sa tunnel traffic lamang. Sa nftables, idagdag ang dalawang linyang ito sa input chain sa /etc/nftables.conf at i-reload gamit ang sudo systemctl reload nftables.

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

Sa ufw, pareho ang ginagawa ng sudo ufw allow in on wg0 to any port 53. Huwag kailanman buksan ang port 53 sa pampublikong internet. Natutuklasan ng mga scanner ang open recursive resolver sa loob ng ilang araw at ginagamit ito para palakihin ang denial-of-service attacks. Mapapansin ng provider mo ang traffic na iyon bago mo ito mapansin.

Muling patakbuhin ang dig +short @10.8.0.1 example.com mula sa client. Nangangahulugan ang address sa output na gumagana ang resolver path, kaya kailangan na lamang itong gamitin ng client. Idagdag ang linya sa [Interface] block ng client at i-restart ang interface gamit ang 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

Ikalawang pagkabigo: tumatagas ang DNS dahil hindi niruruta ng split tunnel ang resolver

Mas malala ito dahil mukhang gumagana ang lahat. Nare-resolve ang mga pangalan, naglo-load ang mga page, at dumadaan nang cleartext ang mga query sa local network na ayaw mong pagkatiwalaan.

Dalawang configuration ang nagdudulot nito. Ang una ay client na may AllowedIPs = 0.0.0.0/0, ::/0 ngunit walang linyang DNS =. Ini-install ng wg-quick ang default route sa sarili nitong routing table at nagdaragdag ng rule gamit ang suppress_prefixlength 0. Sinasadya nitong panatilihing gumagana ang mas espesipikong local route para maabot pa rin ng machine ang printer nito. Ang resolver na natutuhan ng client mula sa DHCP, karaniwang ang router sa 192.168.1.1, ay tumutugma sa isa sa mga local route na iyon. Dumadaan sa tunnel ang traffic mo. Tumatanggap pa rin ang local network ng buong listahan ng mga pangalang hinahanap mo.

Ang ikalawa ay split tunnel: AllowedIPs = 10.8.0.0/24 na may DNS = 9.9.9.9. Dahil wala ang 9.9.9.9 sa loob ng AllowedIPs, walang route ang client papunta rito sa pamamagitan ng tunnel. Kaya lumalabas ang query sa local link, tulad mismo ng unang kaso.

Patunayan kung aling resolver ang aktuwal na sumasagot. Ang whoami.akamai.net ay isang public test name na sumasagot gamit ang IP address ng recursive resolver na nagpadala ng query, kaya maihahambing mo ang sagot nito sa public address ng server mo.

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

Nagpi-print ang resolvectl status ng isang block para sa bawat link. Kung ipinapakita pa rin ng block para sa ethernet o wireless link mo ang Current DNS Server: 192.168.1.1 habang walang ipinapakita ang block na wg0, iyon ang leak. Kinukumpirma ito mula sa malayong endpoint kapag ibinalik ng dig +short whoami.akamai.net ang address ng home broadband mo sa halip na address ng server mo. Ang linyang tcpdump ang tiyak na patunay: sa maayos na output, lahat ng packet sa port 53 ay dumadaan sa wg0; kapag may leak, dumadaan ang mga ito sa wlan0 o enp3s0.

May dalawang bahagi ang pag-aayos, at kailangan ang parehong bahagi. Itakda ang DNS sa isang address na nasa loob ng tunnel, at tiyaking nasa loob ng AllowedIPs ang address na iyon.

[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

Nasa loob ng 10.8.0.0/24 ang 10.8.0.1, kaya naka-encrypt ang query at ipinapadala ito sa server. Kung gagamit ka ng public resolver sa split tunnel, idagdag ito bilang host route: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Pagkatapos, daraan sa tunnel ang mga packet, ngunit makikita pa rin ng local network na pinili mo ang provider na iyon mula sa mga naunang session. Iniiwasan ng resolver na ikaw mismo ang nagpapatakbo ang isyung ito.

Ang pagtatalaga ng resolver ay isa sa mga kapansin-pansing pagkakaiba ng manual na pagbuo ng WireGuard at ng isang coordinated mesh. Bahagi ito ng tradeoff sa WireGuard kumpara sa Tailscale. Sa pagpapatakbo ng sariling Headscale control server, makukuha mo ang coordination na iyon nang hindi ipinagkakatiwala sa third party ang iyong key material.

Pagpalya tatlo: nagkakaroon ng tunggalian ang resolvconf at systemd-resolved sa mga Linux client

Inilalapat ng mga macOS, Windows, iOS at Android client ang DNS = sa pamamagitan ng official app at kaunti ang nagiging problema. Sa Linux nagkakaroon ng isyu, dahil shell script ang naglalapat ng setting at kailangan nitong hulaan kung alin sa ilang resolver manager ang ginagamit mo.

Malinaw ang unang pagpalya. Humihinto ang sudo wg-quick up wg0 at ipinapakita ang:

resolvconf: command not found

Tumatawag ang wg-quick sa resolvconf, ngunit hindi naka-install ang binary na iyon. I-install ang implementation na nakikipag-ugnayan sa systemd-resolved, pagkatapos ay muling i-enable ang interface.

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

Tahimik ang ikalawang pagpalya, at ito ang maaaring gumugol ng isang gabi sa pag-debug. Umaandar ang interface, wastong ipinapakita ng resolvectl status wg0 ang DNS Servers: 10.8.0.1, ngunit ipinapadala pa rin ang mga lookup sa lumang resolver. May hiwalay na resolver list ang systemd-resolved para sa bawat link at pumipili ito ng link para sa bawat query. Kung walang link na minarkahan bilang default route para sa mga pangalan, patuloy nitong ginagamit ang resolver ng wireless link, dahil may search domain ang link na iyon at wala ang sa iyo.

Itakda ang resolver at angkinin ang default route sa iisang hakbang. Lumalawak ang %i sa pangalan ng interface, kaya gumagana ang block na ito nang walang pagbabago sa anumang interface.

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

Tanggalin ang linyang DNS = kapag ginagamit mo ang PostUp sa ganitong paraan, dahil kung hindi, dalawang mechanism ang magsusulat sa resolver state at isa lamang sa mga ito ang magsasagawa ng cleanup pagkatapos. Mahalaga ang argumentong ~.: minamarkahan nito ang wg0 bilang routing domain para sa bawat pangalan, kaya ipinapadala ng systemd-resolved roon ang lahat ng query sa halip na pumili ng link para sa bawat query. I-verify ito.

resolvectl status wg0

May DNS Servers: 10.8.0.1 at Default Route: yes ang healthy output. Kung ang Default Route ay nagbabasa ng no, hindi naisagawa ang bahaging resolvectl domain, at bumalik ka sa pagpili ng link.

May isa pang sitwasyong dapat tukuyin. Kung ang /etc/resolv.conf ay isang aktuwal na file sa halip na symlink patungo sa /run/systemd/resolve/stub-resolv.conf, ibang component ang may kontrol dito, karaniwan ay NetworkManager o isang container runtime. Patakbuhin ang ls -l /etc/resolv.conf bago mag-debug ng iba pa, dahil babaguhin ng tool na sumusulat muli sa file na iyon sa bawat pagbabago sa network ang ginawa mo sa pinakamasamang pagkakataon.

Ang upgrade: sarili mong filtering resolver sa tunnel

Kapag maaasahan nang dumadaan ang mga query sa tunnel, nagiging control point ang resolver sa kabilang dulo. Kapag doon pinatakbo ang AdGuard Home, magkakaroon ang bawat nakakonektang device ng blocklist filtering at query log, nang walang client software at per-device configuration. Ang opisyal na install script, na sinuri noong July 2026, ay isang linya.

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

Sa unang pag-run, nakikinig ang setup wizard sa port 3000. I-access ito sa tunnel sa http://10.8.0.1:3000 sa halip na buksan sa publiko ang port na iyon. Sa wizard, itakda ang DNS listen address at admin listen address sa 10.8.0.1. Kung ginagamit pa rin ng unbound mula sa unang failure ang parehong address, ihinto muna ito gamit ang sudo systemctl disable --now unbound. Hindi maaaring mag-bind ang dalawang proseso sa UDP port 53 sa iisang address, kaya nag-e-exit ang pangalawang proseso na may listen udp 10.8.0.1:53: bind: address already in use.

Walang kailangang baguhin sa mga client config kung nakalagay na roon ang DNS = 10.8.0.1. Ipapakita na ngayon ng query log ang bawat lookup mula sa bawat peer. Isa itong mahalagang desisyon sa privacy, hindi awtomatikong pakinabang: inililipat mo ang tiwala mula sa iyong internet provider papunta sa iyong sarili, at ikaw ang kailangang magpanatiling patched sa server na iyon. Kailangang maayos muna ang mga pangunahing proteksiyon sa isang server na exposed sa internet, at tinatalakay ng unang sampung minuto sa bagong VPS ang mga ito.

FAQ

Bakit kumokonekta ang WireGuard tunnel pero hindi nareresolba ang mga pangalan?

Nagdadala ng mga packet ang tunnel at hindi nito pinoproseso ang mga pangalan, kaya kung gumagana ang tunnel pero sira ang mga lookup, hindi sumasagot ang resolver na itinuro mo. Subukan ang dig +short @10.8.0.1 example.com mula sa client. Ang sagot na communication timed out ay nangangahulugang maaaring walang resolver na nakikinig sa address ng tunnel na iyon, kadalasan dahil ang systemd-resolved stub ay nagbi-bind lamang sa 127.0.0.53, o dina-drop ng server firewall ang UDP port 53 na dumarating sa wg0. Ayusin muna ang listener, saka buksan ang port para lamang sa wg0.

Paano ko susuriin kung nagle-leak ang DNS ko sa WireGuard?

Patakbuhin ang sudo tcpdump -ni any -c 10 port 53 sa client at i-monitor ang column ng interface habang nagba-browse ka. Dapat nasa wg0 ang bawat packet. Kung lumilitaw ang mga ito sa iyong wireless o ethernet interface, lumalabas ang mga query nang hindi naka-encrypt. Nagbibigay ang dig +short whoami.akamai.net ng karagdagang pagsusuri dahil sumasagot ito gamit ang public address ng recursive resolver na nagsagawa ng query, kaya kung hindi address ng iyong server ang sagot, kumpirmado ang leak.

Kailangan ko ba ang linyang DNS = kung gumagamit ako ng split tunnel?

Oo, at dapat nasa loob din ng AllowedIPs ang address ng resolver; kung hindi, walang route ang client papunta rito. Sa AllowedIPs = 10.8.0.0/24, sakop ang resolver na nasa 10.8.0.1 at naka-encrypt ang query. Hindi sakop ang public resolver gaya ng 9.9.9.9, kaya lumalabas ang query sa local link kahit mukhang tama ang linyang DNS.

Bakit ipinapakita ng resolvectl ang tamang server pero sa ibang lugar pa rin napupunta ang mga lookup?

May isang listahan ng resolver ang systemd-resolved para sa bawat link at pumipili ito ng link para sa bawat query, kaya hindi pinapansin ang tamang entry sa wg0 habang may ibang link na may default route para sa mga pangalan. Idagdag ang PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. sa [Interface] block ng client at alisin ang linyang DNS =. Dapat ipakita ng resolvectl status wg0 ang Default Route: yes.

Aling client ang dapat kong ayusin muna kapag marami ang sira?

Ayusin muna ang isang Linux client dahil ito lamang ang platform na nagpapakita ng mekanismo. Ipinapakita ng resolvectl status at tcpdump kung aling resolver ang sumagot at kung aling interface ang nagdala ng packet. Ginagamit ng mga app sa phone at desktop ang parehong mga value ng DNS at AllowedIPs nang walang nakikitang plumbing, kaya kapag tama na ang Linux client, kinokopya mo na lamang ang configuration na napatunayan mo na.