Ayusin ang DNS leak at failure sa WireGuard

Bakit biglang nasisira ang DNS kapag umaandar ang WireGuard tunnel

May tatlong paraan kung paano nabibigo ang DNS over WireGuard, at may sariling solusyon ang bawat isa. Maaaring walang anumang pangalan na ma-resolve, o maaaring nagre-resolve ang mga pangalan pero lumalabas sa tunnel ang mga query mula sa machine mo, o maaaring ma-overwrite ng sariling resolver manager ng client ang setting ilang segundo matapos umandar ang interface. Halos hindi kailanman ang tunnel ang problema. Ang problema ay ang linyang nagsasabi sa client kung aling resolver ang gagamitin, pati ang routing na tumutukoy kung paano dadaan ang mga packet patungo sa resolver na iyon.

Ang WireGuard ay naglilipat ng IP packets 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 DNS = line sa isang client [Interface] block ay hindi WireGuard setting. Binabasa ito ng wg-quick, ang shell wrapper na nagpapagana sa interface, at ine-edit naman ng wg-quick ang resolver configuration ng client habang aktibo ang tunnel at ibinabalik ito sa dati sa wg-quick down. Kaya ang bawat problemang nasa ibaba ay routing problem o wg-quick problem, at hindi kailanman cryptography problem. Kung hindi pa naitatayo ang tunnel mismo, magsimula sa sariling WireGuard VPN sa sarili mong VPS at bumalik sa page na ito pagkatapos.

Tiyaking healthy 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 makatanggap ng sagot ang parehong ping. Kung nagti-time out ang ping 1.1.1.1, forwarding o NAT (network address translation) problem iyon, 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 values.

Unang failure: walang nare-resolve dahil hindi sumasagot ang resolver

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

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

Direktang tanungin ang tunnel resolver mula sa client. Ang dig ay kasama 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 ikalawang command 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 dahilan ang maaaring magdulot nito. Maaaring walang tumatakbong resolver sa server, o maaaring dini-drop ng server firewall ang query bago ito makarating. Suriin ang dalawang ito sa server.

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

Ang resolver na tumatakbo at wastong naka-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 ganitong timeout ang lilitaw.

Ang solusyon 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 public 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 pa ito mapansin.

Ulitin ang dig +short @10.8.0.1 example.com mula sa client. Ang address sa output ay nangangahulugang gumagana ang resolver path, kaya kailangan na lamang itong gamitin ng client. Idagdag ang line 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

Failure two: DNS leaks, because a split tunnel does not route the 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 isang client na may AllowedIPs = 0.0.0.0/0, ::/0 at 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 specific na local route para maabot pa rin ng machine ang printer nito. Ang resolver na natutuhan ng client sa DHCP, karaniwan ay 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 pangalan na hina-hanap mo.

Ang ikalawa ay isang 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, katulad 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. Sa ganitong paraan, maikukumpara 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, samantalang walang ipinapakita ang block na wg0, iyon ang leak. Kinukumpirma ito mula sa kabilang dulo 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 nagbibigay ng tiyak na patunay: sa maayos na output, lahat ng packet sa port 53 ay dumadaan sa wg0. Sa may leak, dumadaan ang mga ito sa wlan0 o enp3s0.

Dalawang bahagi ang fix, at parehong kailangan. Itakda ang DNS sa isang address na nasa loob ng tunnel, at tiyaking nasa loob din 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 ipipilit mong gumamit ng public resolver sa split tunnel, idagdag ito bilang host route: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Dadaan sa tunnel ang mga packet, pero makikita pa rin ng local network na pinili mo ang provider na iyon batay sa mga naunang session. Iniiwasan ng sarili mong resolver ang isyung ito.

Ang pagtatalaga ng resolver ay isa sa mga kapansin-pansing pagkakaiba ng manually built na WireGuard at 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 ang key material mo sa third party. Kung ang huling pariralang iyon ang ikinababahala mo, tandaan na hindi kailanman hinahawakan ng Tailscale ang mga key na nag-e-encrypt ng iyong traffic. Ang mas mahalagang tanong ay kung ano ang maaaring maidagdag sa network mo ng isang compromised coordination server o ninakaw na identity account.

Failure three: resolvconf at systemd-resolved conflict sa mga Linux client

Ang mga macOS, Windows, iOS, at Android client ay nag-a-apply ng DNS = sa pamamagitan ng official app at kaunti ang nagiging problema. Sa Linux, isang shell script ang nag-a-apply ng setting, at kailangan nitong hulaan kung alin sa ilang resolver manager ang ginagamit mo.

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

resolvconf: command not found

Tumatawag ang wg-quick sa resolvconf, pero hindi naka-install ang binary na iyon. I-install ang implementation na kumakausap sa systemd-resolved, at pagkatapos ay i-up ulit 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 failure, at ito ang maaaring umubos ng isang buong gabi. Umaandar ang interface, ipinapakita nang tama ng resolvectl status wg0 ang DNS Servers: 10.8.0.1, pero sa lumang resolver pa rin ipinapadala ang mga lookup. 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 sa iyo.

Itakda ang resolver at i-claim ang default route sa iisang step. Nag-e-expand 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

I-delete ang linyang DNS = kapag ganito mo ginagamit ang PostUp, dahil kung hindi, dalawang mechanism ang magsusulat sa resolver state at isa lamang sa mga ito ang maglilinis pagkatapos. Ang argumentong ~. ang mahalagang bahagi: minamarkahan nito ang wg0 bilang routing domain para sa bawat pangalan, kaya ipinapadala ng systemd-resolved ang lahat ng query doon 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 binabasa ng Default Route ang no, hindi tumakbo ang bahagi ng resolvectl domain, at bumalik ka sa pagpili batay sa link.

May isa pang kasong dapat tukuyin. Kung ang /etc/resolv.conf ay isang aktuwal na file at hindi symlink papunta 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 maaaring i-rewrite ng tool na iyon ang file sa bawat pagbabago sa network at mabura ang ginawa mo sa pinaka-hindi angkop na oras.

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 nagpatakbo ka roon ng AdGuard Home, magkakaroon ang bawat nakakonektang device ng blocklist filtering at query log, nang walang client software at per-device configuration. Ang official install script, na sinuri noong July 2026, ay isang linya lamang.

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

Nakikinig ang setup wizard sa port 3000 sa unang pag-run. I-access ito sa tunnel gamit ang 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 client config kung nakasaad na roon ang DNS = 10.8.0.1. Ipapakita na ngayon ng query log ang bawat lookup mula sa bawat peer. Isa itong aktuwal na desisyon tungkol sa privacy, hindi awtomatikong pakinabang: inililipat mo ang tiwala mula sa internet provider mo papunta sa sarili mo, at ikaw ang kailangang magpanatiling patched sa server na iyon. Kailangang maihanda muna ang mga pangunahing security measure sa server na exposed sa internet, at saklaw ng unang sampung minuto sa bagong VPS ang mga ito.

FAQ

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

Nagdadala ng packets ang tunnel at hindi nito hinahawakan ang mga pangalan, kaya ang gumaganang tunnel na may sirang lookup ay nangangahulugang hindi sumasagot ang resolver na itinuro mo rito. Mag-test gamit ang dig +short @10.8.0.1 example.com mula sa client. Ang reply na communication timed out ay nangangahulugang walang resolver na nakikinig sa tunnel address na iyon, kadalasan dahil ang systemd-resolved stub ay nagbi-bind lamang sa 127.0.0.53, o dahil dini-drop ng server firewall ang UDP port 53 na dumarating sa wg0. Ayusin muna ang listener, saka buksan ang port para sa wg0 lamang.

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

Patakbuhin ang sudo tcpdump -ni any -c 10 port 53 sa client at tingnan ang interface column habang nagba-browse ka. Dapat nasa wg0 ang bawat packet. Kung lumilitaw ang mga ito sa wireless o ethernet interface mo, lumalabas ang mga query nang cleartext. Nagbibigay ang dig +short whoami.akamai.net ng ikalawang pagsusuri dahil sumasagot ito gamit ang public address ng recursive resolver na nagtanong, kaya kinukumpirma ng sagot na hindi address ng server mo ang DNS leak.

Kailangan ko ba ang DNS = line kung split tunnel ang ginagamit ko?

Oo, at dapat nasa loob din ng AllowedIPs ang resolver address; kung hindi, walang route ang client papunta rito. Sa AllowedIPs = 10.8.0.0/24, sakop ang resolver sa 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 tama ang itsura ng DNS line.

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

Nagtatago ang systemd-resolved ng isang resolver list para sa bawat link at pumipili ng link para sa bawat query, kaya binabalewala ang tamang entry sa wg0 kapag 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 DNS = line. Dapat ipakita ng resolvectl status wg0 ang Default Route: yes pagkatapos nito.

Aling client ang dapat kong ayusin muna kapag maraming sira?

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