WireGuard DNS வேலை செய்யாததற்கு 3 காரணங்கள்

WireGuard tunnel தொடங்கியவுடன் DNS ஏன் செயலிழக்கிறது

WireGuard மூலம் DNS பயன்படுத்துவது மூன்று விதங்களில் தோல்வியடையும். ஒவ்வொன்றுக்கும் தனித்தனி தீர்வு உள்ளது. எந்த பெயரும் resolve ஆகாமல் இருக்கலாம். பெயர்கள் resolve ஆனாலும் queries tunnel-க்கு வெளியே, உங்கள் machine-இலிருந்து நேரடியாகச் செல்லலாம். அல்லது interface தொடங்கிய சில விநாடிகளிலேயே client-ன் சொந்த resolver manager அமைப்பை மீண்டும் எழுதலாம். Tunnel பெரும்பாலும் பிரச்சினை அல்ல. Client எந்த resolver-ஐ அணுக வேண்டும் என்று குறிப்பிடும் ஒரு line மற்றும் அந்த resolver-க்கு packets செல்லும் routing ஆகியவையே பொதுவாகக் காரணம்.

WireGuard IP packets-ஐ மட்டும் நகர்த்தும். DNS (domain name system, example.com போன்ற பெயர்களை IP addresses-ஆக மாற்றும் service) பற்றி அதற்கு எதுவும் தெரியாது. Client [Interface] block-இல் உள்ள DNS = line, WireGuard setting அல்ல. Interface-ஐத் தொடங்கும் shell wrapper ஆன wg-quick அதைப் படிக்கும். Tunnel இயங்கும்போது client-ன் resolver configuration-ஐ wg-quick மாற்றும்; wg-quick down நிலையில் அதை மீண்டும் restore செய்யும். எனவே கீழே உள்ள ஒவ்வொரு பிரச்சினையும் routing problem அல்லது wg-quick problem ஆகும்; cryptography problem அல்ல. Tunnel இன்னும் உருவாக்கப்படவில்லை என்றால், முதலில் உங்கள் சொந்த VPS-ல் self-hosted WireGuard VPN அமைப்பது பற்றிய வழிகாட்டியைப் பின்பற்றி, பின்னர் இந்தப் பக்கத்திற்குத் திரும்பவும்.

DNS-ஐ மாற்றுவதற்கு முன் tunnel சரியாக இயங்குகிறதா என்பதை உறுதிப்படுத்தவும்.

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

wg show output-ல் சமீபத்திய latest handshake உடன் peer பட்டியலிடப்பட்டிருக்க வேண்டும். இரண்டு ping-களுக்கும் பதில் வர வேண்டும். ping 1.1.1.1 timeout ஆனால், அது DNS problem அல்ல; forwarding அல்லது NAT (network address translation) problem. Resolver config-ஐ எவ்வளவு மாற்றினாலும் அது சரியாகாது. இங்குள்ள ஒவ்வொரு example-லும் tunnel subnet-ஆக 10.8.0.0/24 மற்றும் server-ன் tunnel address-ஆக 10.8.0.1 பயன்படுத்தப்படுகிறது. உங்கள் சொந்த values-ஐப் பயன்படுத்தவும்.

தோல்வி ஒன்று: resolver பதில் அளிக்காததால் எதுவும் resolve ஆகவில்லை

அறிகுறி தெளிவாக இருக்கும். ping 1.1.1.1 செயல்படும்; curl https://example.com இதைத் திருப்பி அளிக்கும்:

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

Client-இலிருந்து tunnel resolver-ஐ நேரடியாகக் கேளுங்கள். Ubuntu மற்றும் Debian-ல் dig, dnsutils package-லிருந்து கிடைக்கும்.

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

முதல் command ஒரு address-ஐத் திருப்பி அளிக்கிறது. இதனால் tunnel வழியாக packets internet-ஐ அடைகின்றன என்பது உறுதியாகிறது. இரண்டாவது command எந்த output-உம் அளிக்காமல் ;; communication timed out; no servers could be reached-ஐ அச்சிடுகிறது. இதுவே முழு diagnosis: உங்கள் client 10.8.0.1-ஐ பயன்படுத்துமாறு அமைக்கப்பட்டுள்ளது; ஆனால் 10.8.0.1 UDP port 53-ல் பதில் அளிக்கவில்லை.

இதற்கு இரண்டு காரணங்கள் இருக்கலாம். Server-ல் resolver இயங்காமல் இருக்கலாம்; அல்லது query server-ஐ அடையும் முன் server firewall அதை drop செய்யலாம். Server-ல் இரண்டையும் சரிபார்க்கவும்.

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

சரியாக இயங்கி bind செய்யப்பட்ட resolver, 10.8.0.1:53 அல்லது 0.0.0.0:53 கொண்ட ஒரு line-ஐக் காட்டும். Ubuntu-ல் பொதுவாக ஏற்படும் குழப்பம் 127.0.0.53:53 ஆகும். இது systemd-resolved stub listener. இது loopback address-க்கு bind செய்யப்பட்டு, பிற machines-லிருந்து திட்டமிட்டு அணுக முடியாதபடி இருக்கும். ஒரே resolver ஆக அந்த stub மட்டுமே உள்ள server-ஐ VPN client பயன்படுத்துமாறு அமைத்தால், இதே timeout ஏற்படும்.

இதற்கான தீர்வு, tunnel address-ல் listen செய்யும் resolver-ஐ அமைப்பதும், peers அதை அணுக அனுமதிக்கும் ஒரு firewall rule-ஐச் சேர்ப்பதும் ஆகும்.

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'

அடுத்து tunnel traffic-க்கு மட்டும் port-ஐத் திறக்கவும். nftables பயன்படுத்தினால், /etc/nftables.conf-ல் உள்ள input chain-க்கு இந்த இரண்டு lines-ஐச் சேர்த்து, sudo systemctl reload nftables மூலம் reload செய்யவும்.

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

ufw பயன்படுத்தினால், sudo ufw allow in on wg0 to any port 53 அதே பணியைச் செய்யும். Port 53-ஐ public internet-க்கு ஒருபோதும் திறக்க வேண்டாம். திறந்த recursive resolver-ஐ scanners சில நாட்களிலேயே கண்டறிந்து denial of service attacks-ஐ amplify செய்ய பயன்படுத்திவிடும். நீங்கள் கவனிப்பதற்கு முன்பே உங்கள் provider அந்த traffic-ஐக் கவனிப்பார்.

Client-லிருந்து dig +short @10.8.0.1 example.com-ஐ மீண்டும் இயக்கவும். Output-ல் ஒரு address கிடைத்தால் resolver path செயல்படுகிறது. இப்போது client அந்த resolver-ஐப் பயன்படுத்துமாறு அமைத்தால் போதும். அந்த line-ஐ client-ன் [Interface] block-ல் சேர்த்து, sudo wg-quick down wg0 && sudo wg-quick up wg0 மூலம் interface-ஐ restart செய்யவும்.

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

தோல்வி இரண்டு: split tunnel resolver-ஐ route செய்யாததால் DNS leaks

இந்தப் பிரச்சினை மோசமானது, ஏனெனில் அனைத்தும் சரியாக இயங்குவது போலத் தெரியும். Names resolve ஆகும், pages load ஆகும். ஆனால் queries, நீங்கள் நம்ப விரும்பாத local network வழியாக cleartext-ஆக செல்கின்றன.

இதை இரண்டு configurations ஏற்படுத்தும். முதலாவது, AllowedIPs = 0.0.0.0/0, ::/0 உள்ள client-ல் DNS = line இல்லாத நிலை. wg-quick தனது சொந்த routing table-ல் default route-ஐ நிறுவி, suppress_prefixlength 0 உடன் ஒரு rule-ஐ சேர்க்கும். இதனால் மேலும் குறிப்பிட்ட local routes திட்டமிட்டு செயல்பாட்டில் இருக்கும்; எனவே machine தனது printer-ஐ இன்னும் அணுக முடியும். Client DHCP மூலம் கற்ற resolver, பொதுவாக 192.168.1.1-ல் இருக்கும் router, அந்த local routes-ல் ஒன்றுடன் பொருந்தும். உங்கள் traffic tunnel வழியாக செல்கிறது. ஆனால் நீங்கள் lookup செய்யும் முழு names பட்டியலையும் local network இன்னும் பெறுகிறது.

இரண்டாவது, split tunnel: AllowedIPs = 10.8.0.0/24 உடன் DNS = 9.9.9.9. 9.9.9.9, AllowedIPs-க்குள் இல்லாததால், client அதனை tunnel வழியாக அணுக route வைத்திருக்காது. எனவே query, முதல் நிலைபோலவே local link வழியாக வெளியேறும்.

உண்மையில் எந்த resolver பதிலளிக்கிறது என்பதை நிரூபிக்கவும். whoami.akamai.net என்பது, query அனுப்பிய recursive resolver-ன் IP address-ஐ பதிலாக வழங்கும் public test name. அதன் பதிலை உங்கள் server-ன் public address-உடன் ஒப்பிடலாம்.

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

resolvectl status ஒவ்வொரு link-க்கும் ஒரு block-ஐ வெளியிடும். உங்கள் ethernet அல்லது wireless link-க்கான block-ல் இன்னும் Current DNS Server: 192.168.1.1 காட்டப்பட்டும், wg0 block-ல் எதுவும் காட்டப்படாமலும் இருந்தால், அதுவே leak. dig +short whoami.akamai.net உங்கள் server-ன் address-க்கு பதிலாக home broadband address-ஐ வழங்கினால், தொலைநிலைப் பக்கத்திலிருந்தும் இதை உறுதிப்படுத்தலாம். விவாதத்தை முடிக்கும் ஆதாரம் tcpdump line ஆகும்: சரியான output-ல் port 53 packets அனைத்தும் wg0 வழியாகச் செல்லும்; leak இருந்தால் அவை wlan0 அல்லது enp3s0 வழியாகச் செல்லும்.

இதற்கான fix இரண்டு பகுதிகளைக் கொண்டது. இரண்டும் அவசியம். DNS-ஐ tunnel-க்குள் இருக்கும் address-ஆக அமைக்கவும். அந்த address, 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, 10.8.0.0/24-க்குள் இருப்பதால் query encrypted-ஆகி server-க்கு அனுப்பப்படும். Split tunnel-ல் public resolver-ஐ பயன்படுத்த வேண்டும் என்றால், அதனை host route-ஆகச் சேர்க்கவும்: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. அதன் பிறகு packets tunnel வழியாகச் செல்லும். இருப்பினும், முந்தைய sessions-ல் நீங்கள் அந்த provider-ஐத் தேர்ந்தெடுத்ததை local network அறியக்கூடும். நீங்களே இயக்கும் resolver இந்தக் கேள்வியைத் தவிர்க்கும்.

Resolver assignment என்பது கையால் அமைக்கப்பட்ட WireGuard மற்றும் coordinated mesh ஆகியவற்றுக்கிடையிலான வெளிப்படையான வேறுபாடுகளில் ஒன்றாகும். இது WireGuard-ஐ Tailscale-உடன் ஒப்பிடும்போது காணப்படும் tradeoff-ன் ஒரு பகுதியாகும். self-hosted Headscale control server-ஐ இயக்குவதன் மூலம், உங்கள் key material-ஐ third party-க்கு வழங்காமல் அந்த coordination-ஐப் பெறலாம். கடைசி கூற்று உங்களுக்கு கவலையாக இருந்தால், உங்கள் traffic-ஐ encrypt செய்யும் keys-ஐ Tailscale ஒருபோதும் வைத்திருக்காது என்பதை நினைவில் கொள்ளுங்கள். அதற்குப் பதிலாக, compromised coordination server அல்லது திருடப்பட்ட identity account உங்கள் network-க்கு என்ன கூடுதல் அணுகலை வழங்கக்கூடும் என்பதே முக்கியமான கேள்வியாகும்.

தோல்வி மூன்று: Linux clients-ல் resolvconf மற்றும் systemd-resolved மோதல்

macOS, Windows, iOS மற்றும் Android clients அதிகாரப்பூர்வ app மூலம் DNS =-ஐப் பயன்படுத்துகின்றன; எனவே அவை பெரும்பாலும் சிக்கலை ஏற்படுத்தாது. Linux-ல் இந்த setting-ஐ shell script பயன்படுத்துகிறது. நீங்கள் பயன்படுத்தும் பல resolver managers-ல் எது என்பதை அந்த script ஊகிக்க வேண்டியுள்ளது.

முதல் தோல்வி வெளிப்படையாகத் தெரியும். sudo wg-quick up wg0 இதனுடன் நிற்கிறது:

resolvconf: command not found

wg-quick, resolvconf-ஐ அழைக்கிறது; ஆனால் அந்த binary நிறுவப்படவில்லை. systemd-resolved-உடன் தொடர்புகொள்ளும் implementation-ஐ நிறுவி, அதன் பிறகு interface-ஐ மீண்டும் இயக்கவும்.

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

இரண்டாவது தோல்வி அமைதியாக நிகழும். இதுவே ஒரு மாலை நேரத்தை முழுவதும் செலவழிக்கச் செய்யும். Interface இயங்கத் தொடங்குகிறது, resolvectl status wg0 சரியாக DNS Servers: 10.8.0.1-ஐக் காட்டுகிறது; இருந்தாலும் lookups பழைய resolver-க்கே செல்கின்றன. systemd-resolved ஒவ்வொரு link-க்கும் தனித்தனி resolver list-ஐ வைத்திருந்து, ஒவ்வொரு query-க்கும் ஒரு link-ஐத் தேர்ந்தெடுக்கிறது. Names-க்கான default route ஆக எந்த link-மும் குறிக்கப்படவில்லை என்றால், அது wireless link-ன் resolver-ஐத் தொடர்ந்து பயன்படுத்தும். காரணம், அந்த link-ல் search domain உள்ளது; உங்கள் link-ல் இல்லை.

அதே step-ல் resolver-ஐ அமைத்து, default route-ஐக் கோரவும். %i interface name-ஆக விரிவடையும். எனவே இந்த block எந்த interface-லும் மாற்றமின்றி செயல்படும்.

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

இந்த முறையில் PostUp-ஐப் பயன்படுத்தும்போது DNS = line-ஐ நீக்கவும். இல்லையெனில் இரண்டு mechanisms resolver state-ஐ எழுதும்; பின்னர் அவற்றில் ஒன்று மட்டும் cleanup செய்யும். ~. argument முக்கியமான பகுதி. இது wg0-ஐ அனைத்து names-க்கும் routing domain-ஆகக் குறிக்கும். எனவே systemd-resolved ஒவ்வொரு query-க்கும் link-ஐத் தேர்ந்தெடுப்பதற்குப் பதிலாக, அனைத்து queries-ஐயும் அங்கே அனுப்பும். இதைச் சரிபார்க்கவும்.

resolvectl status wg0

சரியான output-ல் DNS Servers: 10.8.0.1 மற்றும் Default Route: yes இருக்கும். Default Route, no என்று காட்டினால், resolvectl domain பகுதி இயங்கவில்லை. அப்போது மீண்டும் link selection முறைக்குத் திரும்பிவிட்டீர்கள்.

மேலும் ஒரு நிலையை குறிப்பிட வேண்டும். /etc/resolv.conf, /run/systemd/resolve/stub-resolv.conf-க்கான symlink ஆக இல்லாமல் உண்மையான file-ஆக இருந்தால், அதை வேறு ஏதோ ஒன்று நிர்வகிக்கிறது. பொதுவாக அது NetworkManager அல்லது container runtime ஆக இருக்கும். வேறு எதையும் debug செய்வதற்கு முன் ls -l /etc/resolv.conf-ஐ இயக்கவும். ஒவ்வொரு network மாற்றத்தின்போதும் அந்த file-ஐ மீண்டும் எழுதும் tool, மிகவும் தவறான நேரத்தில் உங்கள் மாற்றத்தை அழித்துவிடும்.

upgrade: tunnel வழியாக இயங்கும் உங்கள் சொந்த filtering resolver

Queries நம்பகமாக tunnel வழியாகச் செல்லத் தொடங்கியதும், மறுபுறத்தில் உள்ள resolver ஒரு control point ஆகிறது. அங்கு AdGuard Home இயக்கினால், client software அல்லது ஒவ்வொரு device-க்குமான தனிப்பட்ட configuration இல்லாமல், இணைக்கப்பட்ட அனைத்து devices-க்கும் blocklist filtering மற்றும் query log கிடைக்கும். July 2026 அன்று சரிபார்க்கப்பட்ட official install script ஒரே வரியாகும்.

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

முதல் முறையாக இயக்கும்போது setup wizard port 3000-ல் listen செய்யும். அந்த port-ஐ பொதுவாகத் திறப்பதற்குப் பதிலாக tunnel வழியாக http://10.8.0.1:3000-ல் அதை அணுகவும். Wizard-ல் DNS listen address மற்றும் admin listen address இரண்டையும் 10.8.0.1 ஆக அமைக்கவும். முதல் failure-இல் உள்ள unbound இன்னும் அதே address-ஐ பயன்படுத்தினால், முதலில் sudo systemctl disable --now unbound மூலம் அதை நிறுத்தவும். ஒரே address-ல் UDP port 53-ஐ இரண்டு processes bind செய்ய முடியாது; எனவே இரண்டாவது process listen udp 10.8.0.1:53: bind: address already in use உடன் வெளியேறும்.

ஏற்கனவே DNS = 10.8.0.1 என்று குறிப்பிடப்பட்டிருந்தால், client configs-ல் எந்த மாற்றமும் தேவையில்லை. இப்போது query log ஒவ்வொரு peer-இலிருந்தும் வரும் ஒவ்வொரு lookup-ஐயும் காட்டும். இது இலவச நன்மை அல்ல; உண்மையான privacy முடிவாகும். Trust-ஐ உங்கள் internet provider-இலிருந்து உங்களிடம் மாற்றுகிறீர்கள். அந்த server-ஐ patched நிலையில் வைத்திருப்பது உங்கள் பொறுப்பு. Internet-க்கு exposed செய்யப்பட்ட server-ல் அடிப்படை security அமைப்புகள் முதலில் இருக்க வேண்டும். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் அவற்றை விளக்குகிறது.

FAQ

என் WireGuard tunnel இணைந்தாலும் names ஏன் resolve ஆகவில்லை?

Tunnel packets-ஐ மட்டும் எடுத்துச் செல்லும்; names-ஐ அது கையாளாது. எனவே tunnel இயங்கியும் lookups தோல்வியடைந்தால், நீங்கள் குறிப்பிடும் resolver பதிலளிக்கவில்லை என்பதே காரணம். Client-ல் dig +short @10.8.0.1 example.com மூலம் சோதிக்கவும். communication timed out reply கிடைத்தால், அந்த tunnel address-ல் எந்த resolver-ம் listening செய்யவில்லை என்பதோ, அல்லது systemd-resolved stub 127.0.0.53-க்கு மட்டும் bind ஆகி இருப்பதோ காரணமாக இருக்கலாம். மேலும், server firewall wg0 வழியாக வரும் UDP port 53 traffic-ஐ drop செய்திருக்கலாம். முதலில் listener-ஐ சரிசெய்யவும். பின்னர் wg0-க்கு மட்டும் port-ஐ திறக்கவும்.

WireGuard வழியாக என் DNS leak ஆகிறதா என்பதை எப்படி சரிபார்ப்பது?

Client-ல் sudo tcpdump -ni any -c 10 port 53 இயக்கி, browse செய்யும் போது interface column-ஐ monitor செய்யவும். ஒவ்வொரு packet-உம் wg0 வழியாகச் செல்ல வேண்டும். அவை wireless அல்லது ethernet interface-ல் தோன்றினால், queries cleartext-ஆக வெளியேறுகின்றன. dig +short whoami.akamai.net மூலம் இரண்டாவது சரிபார்ப்பையும் செய்யலாம். அது query அனுப்பிய recursive resolver-ன் public address-ஐ பதிலாக வழங்கும். எனவே உங்கள் server address அல்லாத address கிடைத்தால், DNS leak உறுதியாகிறது.

Split tunnel பயன்படுத்தினால் DNS = line தேவைப்படுமா?

ஆம். Resolver address AllowedIPs-க்குள்ளும் இருக்க வேண்டும். இல்லையெனில் client-க்கு அந்த address-க்கு route இருக்காது. AllowedIPs = 10.8.0.0/24 இருந்தால், 10.8.0.1-ல் உள்ள resolver அந்த range-க்குள் வரும்; query encrypted-ஆக இருக்கும். 9.9.9.9 போன்ற public resolver அந்த range-க்குள் வராது. எனவே DNS line சரியாகத் தோன்றினாலும், query local link வழியாக வெளியேறும்.

resolvectl சரியான server-ஐ காட்டினாலும் lookups ஏன் வேறு இடத்துக்குச் செல்கின்றன?

systemd-resolved ஒவ்வொரு link-க்கும் தனித்தனி resolver list-ஐ வைத்திருக்கும். ஒவ்வொரு query-க்கும் அது ஒரு link-ஐத் தேர்ந்தெடுக்கும். எனவே wg0-ல் சரியான entry இருந்தாலும், names-க்கான default route வேறு link-ல் இருந்தால் அந்த entry புறக்கணிக்கப்படும். Client-ன் [Interface] block-ல் PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~.-ஐச் சேர்த்து, DNS = line-ஐ அகற்றவும். பின்னர் resolvectl status wg0, Default Route: yes-ஐ report செய்ய வேண்டும்.

பல client-கள் பாதிக்கப்பட்டிருக்கும்போது முதலில் எந்த client-ஐ சரிசெய்ய வேண்டும்?

ஒரு Linux client-ஐ முதலில் சரிசெய்யவும். Mechanism எவ்வாறு செயல்படுகிறது என்பதை வெளிப்படையாகக் காட்டும் ஒரே platform அது. எந்த resolver பதிலளித்தது, எந்த interface packet-ஐ எடுத்துச் சென்றது என்பதை resolvectl status மற்றும் tcpdump காட்டும். Phone மற்றும் desktop applications அதே DNS மற்றும் AllowedIPs values-ஐ visible plumbing இல்லாமல் பயன்படுத்தும். எனவே Linux client சரியாக இயங்கியதும், ஏற்கனவே நிரூபித்த configuration-ஐ copy செய்யலாம்.