WireGuard DNS செயலிழப்பை சரிசெய்யும் 3 வழிகள்

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

WireGuard வழியாக DNS 3 விதங்களில் செயலிழக்கலாம். ஒவ்வொன்றுக்கும் தனித்தனி தீர்வு உள்ளது. எந்தப் பெயரும் 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 திருத்துகிறது. Tunnel நிறுத்தப்படும்போது அதை wg-quick down மீட்டமைக்கிறது. எனவே கீழே உள்ள ஒவ்வொரு பிரச்சினையும் routing பிரச்சினை அல்லது wg-quick பிரச்சினை ஆகும்; cryptography பிரச்சினை அல்ல. 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, சமீபத்திய latest handshake உடன் peer-ஐ பட்டியலிட வேண்டும். இரு ping-களுக்கும் பதில் வர வேண்டும். ping 1.1.1.1 timeout ஆனால், அது DNS பிரச்சினை அல்ல; forwarding அல்லது NAT (network address translation) பிரச்சினையாகும். Resolver config-ஐ எவ்வளவு மாற்றினாலும் அது உதவாது. இங்குள்ள ஒவ்வொரு எடுத்துக்காட்டிலும் tunnel subnet-க்கு 10.8.0.0/24 மற்றும் server-ன் tunnel address-க்கு 10.8.0.1 பயன்படுத்தப்படுகிறது. உங்கள் சொந்த மதிப்புகளைப் பயன்படுத்தவும்.

தோல்வி ஒன்று: 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 இணையத்தை அடைகின்றன என்பது உறுதியாகிறது. இரண்டாவது command எதையும் திருப்பி அளிக்காமல் ;; 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 கொண்ட ஒரு வரியைக் காட்டும். 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-ஐ பெருக்குவதற்குப் பயன்படுத்தும். நீங்கள் கவனிப்பதற்கு முன்பே உங்கள் 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 கசிவுகள்

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

இதை இரண்டு configurations ஏற்படுத்தும். முதலில், AllowedIPs = 0.0.0.0/0, ::/0 உள்ள client-ல் DNS = line இல்லாத நிலை. wg-quick தனது சொந்த routing table-ல் default route-ஐ நிறுவி, suppress_prefixlength 0 உடன் ஒரு rule-ஐச் சேர்க்கும். இதனால், அந்த machine தனது printer-ஐ இன்னும் அணுகக்கூடிய வகையில், அதிகக் குறிப்பிட்ட local routes திட்டமிட்டு செயல்பாட்டில் இருக்கும். DHCP மூலம் client கற்ற resolver, பொதுவாக 192.168.1.1-ல் உள்ள router, அந்த local routes-களில் ஒன்றுடன் பொருந்தும். உங்கள் traffic tunnel வழியாகச் செல்லும். ஆனால் நீங்கள் lookup செய்யும் பெயர்களின் முழுப் பட்டியலையும் 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-ல் எதுவும் காட்டப்படவில்லை என்றால், அதுவே கசிவு. dig +short whoami.akamai.net உங்கள் server-ன் address-க்கு பதிலாக வீட்டின் broadband address-ஐத் திருப்பித் தருவது, remote end-லிருந்தும் இதை உறுதிப்படுத்தும். விவாதத்தை முடிவுக்குக் கொண்டுவரும் ஆதாரம் tcpdump line ஆகும்: சரியான output-ல் port 53 packets அனைத்தும் wg0 வழியாகச் செல்லும்; கசிவு ஏற்பட்டால் அவை wlan0 அல்லது enp3s0 வழியாகச் செல்லும்.

இந்தச் சிக்கலுக்கான தீர்வில் இரண்டு பகுதிகள் உள்ளன. இரண்டும் அவசியம். 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-க்கும் ஒருங்கிணைக்கப்பட்ட mesh-க்கும் இடையிலான வெளிப்படையான வேறுபாடுகளில் ஒன்றாகும். இது WireGuard மற்றும் Tailscale ஒப்பீடு-ல் குறிப்பிடப்படும் tradeoff-ன் ஒரு பகுதியாகும். self-hosted Headscale control server-ஐ இயக்குவது, உங்கள் key material-ஐ third party-யிடம் ஒப்படைக்காமல் அந்த coordination-ஐ வழங்குகிறது.

தோல்வி மூன்று: Linux clients இல் resolvconf மற்றும் systemd-resolved ஒன்றுடன் ஒன்று முரண்படுதல்

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

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

resolvconf: command not found

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

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

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

Resolver-ஐ அமைத்து, அதே படியில் default route-ஐக் குறிப்பிடுங்கள். %i interface பெயராக விரிவடைவதால், இந்த 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 = வரியை நீக்குங்கள். இல்லையெனில் இரண்டு mechanisms resolver state-ஐ எழுதும்; பின்னர் அவற்றில் ஒன்று மட்டுமே cleanup செய்யும். ~. argument மிகவும் முக்கியமானது. அது wg0-ஐ ஒவ்வொரு name-க்கும் 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 ஒரு கட்டுப்பாட்டு புள்ளியாகிறது. அங்கே AdGuard Home இயக்கினால், இணைக்கப்பட்ட ஒவ்வொரு device-க்கும் client software அல்லது ஒவ்வொரு device-க்குமான தனிப்பட்ட configuration இன்றி blocklist filtering மற்றும் query log கிடைக்கும். 2026 July-ல் சரிபார்க்கப்பட்ட 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-ஆக அமைக்கவும். முதல் தோல்வியிலிருந்து மீதமுள்ள unbound அதே address-ஐ இன்னும் பயன்படுத்தினால், முதலில் sudo systemctl disable --now unbound மூலம் அதை நிறுத்தவும். ஒரே address-ல் இரண்டு processes UDP port 53-ஐ 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 நிலையில் வைத்திருப்பது உங்கள் பொறுப்பு. இணையத்திற்கு exposed செய்யப்பட்ட server-ல் முதலில் அடிப்படை பாதுகாப்புகள் அமைக்கப்பட்டிருக்க வேண்டும். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் அவற்றை விளக்குகிறது.

FAQ

எனது WireGuard tunnel இணைந்தாலும் பெயர்கள் ஏன் resolve ஆகவில்லை?

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

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

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

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

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

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

systemd-resolved ஒவ்வொரு link-க்கும் தனித்தனி resolver list-ஐ வைத்திருக்கும். ஒவ்வொரு query-க்கும் அது ஒரு link-ஐத் தேர்ந்தெடுக்கும். எனவே wg0-இல் சரியான entry இருந்தாலும், மற்றொரு link names-க்கான default route-ஐ வைத்திருந்தால் அந்த 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-ஐ முதலில் சரிசெய்யவும். செயல்முறை எவ்வாறு நடக்கிறது என்பதைத் தெளிவாகக் காட்டும் ஒரே platform அதுவாகும். எந்த resolver பதிலளித்தது, எந்த interface packet-ஐ எடுத்துச் சென்றது என்பதை resolvectl status மற்றும் tcpdump காட்டும். Phone மற்றும் desktop apps, காணக்கூடிய plumbing இல்லாமல், அதே DNS மற்றும் AllowedIPs values-ஐப் பயன்படுத்தும். ஆகவே Linux client சரியானதும், ஏற்கனவே சரிபார்த்த configuration-ஐ நகலெடுக்கலாம்.