WireGuard में DNS ठीक करने के 3 तरीके

WireGuard tunnel शुरू होते ही DNS क्यों विफल हो जाता है

WireGuard पर DNS तीन तरीकों से विफल होता है, और हर तरीके का अलग समाधान है। कुछ भी resolve नहीं होता। या नाम resolve होते हैं, लेकिन queries tunnel के बाहर आपकी मशीन से निकलती हैं। या interface शुरू होने के कुछ ही सेकंड बाद client का अपना resolver manager इस setting को बदल देता है। समस्या लगभग कभी भी tunnel में नहीं होती। समस्या उस एक line में होती है जो client को बताती है कि किस resolver से पूछना है, और उस routing में होती है जो तय करती है कि उस resolver तक packets कैसे जाएंगे।

WireGuard IP packets को स्थानांतरित करता है और DNS (domain name system, वह service जो example.com जैसे नामों को IP addresses में बदलती है) के बारे में कुछ नहीं जानता। Client के [Interface] block में मौजूद DNS = line WireGuard setting नहीं है। इसे wg-quick पढ़ता है, जो interface को शुरू करने वाला shell wrapper है। इसके बाद wg-quick tunnel सक्रिय रहने के दौरान client के resolver configuration को बदलता है और wg-quick down पर उसे पुनर्स्थापित करता है। इसलिए नीचे दी गई हर समस्या routing की समस्या या wg-quick की समस्या है, cryptography की समस्या नहीं। यदि tunnel अभी बना नहीं है, तो अपने VPS पर self-hosted WireGuard VPN से शुरुआत करें और उसके बाद इस page पर वापस आएं।

DNS में कोई बदलाव करने से पहले पुष्टि करें कि tunnel ठीक है।

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

wg show में peer के साथ हाल का latest handshake दिखना चाहिए और दोनों ping का उत्तर मिलना चाहिए। यदि ping 1.1.1.1 timeout हो जाता है, तो समस्या DNS की बजाय forwarding या NAT (network address translation) की है। Resolver configuration की कोई भी मात्रा इसमें सहायता नहीं करेगी। यहां प्रत्येक उदाहरण में tunnel subnet के लिए 10.8.0.0/24 और server के tunnel address के लिए 10.8.0.1 का उपयोग किया गया है। अपने values का उपयोग करें।

विफलता एक: कुछ भी resolve नहीं होता, क्योंकि resolver कभी उत्तर नहीं देता

लक्षण स्पष्ट है। ping 1.1.1.1 काम करता है, और curl https://example.com यह लौटाता है:

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

क्लाइंट से 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 लौटाती है। इससे सिद्ध होता है कि packets tunnel के माध्यम से internet तक पहुँच रहे हैं। दूसरी command कुछ नहीं लौटाती और ;; communication timed out; no servers could be reached प्रिंट करती है। यही पूरा diagnosis है: आपका client 10.8.0.1 पर pointed है और 10.8.0.1 UDP port 53 पर उत्तर नहीं दे रहा है।

इसके दो कारण हो सकते हैं। या तो server पर कोई resolver चल नहीं रहा है, या server firewall query को पहुँचने से पहले drop कर रहा है। Server पर दोनों की जाँच करें।

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

सही तरीके से चल रहा और bound 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 से जानबूझकर unreachable रहता है। VPN client को ऐसे server पर point करने से, जिसके पास केवल यही resolver है, ठीक यही timeout उत्पन्न होता है।

समाधान ऐसा resolver है जो tunnel address पर listen करे, और 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 के साथ, input chain में /etc/nftables.conf की इन दो 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 के लिए कभी न खोलें। Open recursive resolver को scanners कुछ ही दिनों में खोज लेते हैं और denial of service attacks को amplify करने के लिए इस्तेमाल करते हैं। आपका provider इस traffic को आपसे पहले देख लेगा।

Client से dig +short @10.8.0.1 example.com फिर चलाएँ। Output में कोई address मिलने का अर्थ है कि resolver path काम कर रहा है। अब client को केवल उसका उपयोग करना है। यह 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

विफलता दो: DNS लीक, क्योंकि split tunnel resolver को route नहीं करता

यह समस्या अधिक गंभीर है, क्योंकि सब कुछ काम करता हुआ दिखाई देता है। नाम resolve होते हैं, पेज लोड होते हैं, और queries उस local network पर cleartext में जाती हैं जिस पर आप भरोसा नहीं करना चाहते थे।

इसके दो कारण हैं। पहला कारण ऐसा client है जिसमें AllowedIPs = 0.0.0.0/0, ::/0 है, लेकिन DNS = line नहीं है। wg-quick अपनी routing table में default route install करता है और suppress_prefixlength 0 के साथ एक rule जोड़ता है। इससे अधिक specific local routes जानबूझकर सक्रिय रहते हैं, ताकि machine अभी भी अपने printer तक पहुंच सके। Client ने DHCP से जो resolver सीखा है, आमतौर पर 192.168.1.1 पर मौजूद router, वह इन्हीं local routes में से एक से match करता है। आपका traffic tunnel से होकर जाता है। Local network को आपके द्वारा lookup किए गए नामों की पूरी सूची फिर भी मिलती रहती है।

दूसरा कारण 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 एक public test name है। यह उस recursive resolver का IP address लौटाता है जिसने query भेजी थी। इससे आप उसके उत्तर की तुलना अपने 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 को लौटाना remote end से इसकी पुष्टि करता है। tcpdump line वह निर्णायक प्रमाण है: सही output में प्रत्येक port 53 packet wg0 पर जाता है, जबकि leak की स्थिति में वे wlan0 या enp3s0 पर जाते हैं।

इस समस्या के समाधान के दो भाग हैं, और दोनों आवश्यक हैं। DNS को ऐसे address पर set करें जो tunnel के अंदर मौजूद हो। यह भी सुनिश्चित करें कि वह 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 से होकर जाते हैं। हालांकि local network अभी भी पिछले sessions से यह देख सकता है कि आपने कौन-सा provider चुना है। अपना resolver चलाने से यह समस्या समाप्त हो जाती है।

Resolver assignment, hand-built WireGuard और coordinated mesh के बीच दिखाई देने वाले प्रमुख अंतर में से एक है। यह WireGuard की Tailscale के साथ तुलना में बताए गए tradeoff का हिस्सा है। self-hosted Headscale control server चलाने से आपको यह coordination मिलती है, और आपको अपना key material किसी third party को नहीं देना पड़ता।

विफलता तीन: Linux क्लाइंट पर resolvconf और systemd-resolved में टकराव

macOS, Windows, iOS और Android क्लाइंट आधिकारिक app के माध्यम से DNS = लागू करते हैं और बहुत कम समस्याएँ उत्पन्न करते हैं। Linux में यह setting एक shell script द्वारा लागू होती है, जिसे यह अनुमान लगाना पड़ता है कि कई resolver manager में से आप किसका उपयोग करते हैं।

पहली विफलता स्पष्ट होती है। sudo wg-quick up wg0 इस संदेश के साथ रुक जाता है:

resolvconf: command not found

wg-quick, resolvconf को चलाने का प्रयास करता है, लेकिन वह binary installed नहीं है। ऐसा implementation install करें जो systemd-resolved के साथ संचार करता हो। इसके बाद 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 दिखाता है, फिर भी lookups पुराने resolver को भेजे जाते हैं। systemd-resolved प्रत्येक link के लिए अलग resolver list रखता है और प्रत्येक query के लिए एक link चुनता है। जब तक किसी एक link को names के लिए default route के रूप में चिह्नित नहीं किया जाता, यह wireless link के resolver का उपयोग करता रहता है, क्योंकि उस link में search domain है और आपके link में नहीं है।

Resolver set करें और उसी step में default route का दावा करें। %i interface name में expand होता है, इसलिए यह 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 को प्रत्येक name के लिए routing domain के रूप में चिह्नित करता है, इसलिए systemd-resolved प्रत्येक query के लिए link चुनने के बजाय सभी queries वहीं भेजता है। इसे verify करें।

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 है, तो कोई अन्य component उसका स्वामी है। आमतौर पर यह NetworkManager या container runtime होता है। किसी अन्य debugging से पहले ls -l /etc/resolv.conf चलाएँ, क्योंकि प्रत्येक network change पर उस file को फिर से लिखने वाला tool सबसे अनुपयुक्त समय पर आपके बदलाव को हटा देगा।

टनल के ऊपर अपना फ़िल्टरिंग resolver: अपग्रेड

जब queries विश्वसनीय रूप से tunnel से होकर जाने लगती हैं, तो दूसरे छोर का resolver नियंत्रण बिंदु बन जाता है। वहां AdGuard Home चलाने से जुड़े हर device को blocklist filtering और query log मिलता है। इसके लिए client software या हर device का अलग configuration आवश्यक नहीं है। July 2026 में जांची गई official install script एक line की है।

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 पर set करें। यदि failure one से unbound अभी भी वही address पर चल रहा है, तो पहले उसे sudo systemctl disable --now unbound से stop करें। एक ही address पर दो processes UDP port 53 से bind नहीं हो सकते। दूसरा process listen udp 10.8.0.1:53: bind: address already in use के साथ exit हो जाता है।

यदि client configs में पहले से DNS = 10.8.0.1 लिखा है, तो उनमें कोई बदलाव आवश्यक नहीं है। अब query log हर peer से होने वाली प्रत्येक lookup दिखाएगा। यह बिना लागत का लाभ नहीं, बल्कि वास्तविक privacy decision है। आप trust अपने internet provider से हटाकर स्वयं पर डालते हैं। उस box को patched रखना भी आपकी जिम्मेदारी है। Internet के सामने exposed server पर पहले बुनियादी सुरक्षा उपाय लागू होने चाहिए। नए VPS पर पहले दस मिनट में इनका विवरण है।

FAQ

मेरा WireGuard टनल कनेक्ट होता है, लेकिन नाम resolve क्यों नहीं होते?

टनल पैकेट ले जाता है और नामों को बिल्कुल हैंडल नहीं करता। इसलिए काम कर रहे टनल के साथ lookup विफल होने का अर्थ है कि जिस resolver को आप निर्दिष्ट कर रहे हैं, वह उत्तर नहीं दे रहा है। क्लाइंट से dig +short @10.8.0.1 example.com द्वारा परीक्षण करें। communication timed out का उत्तर मिलने का अर्थ है कि या तो उस टनल पते पर कोई resolver listen नहीं कर रहा है, जो अक्सर इसलिए होता है क्योंकि systemd-resolved stub केवल 127.0.0.53 पर bind होता है, या server firewall wg0 पर आने वाले UDP port 53 को drop कर रहा है। पहले listener को ठीक करें। फिर port को केवल wg0 के लिए खोलें।

मैं कैसे जांचूं कि मेरा DNS WireGuard पर leak हो रहा है?

क्लाइंट पर sudo tcpdump -ni any -c 10 port 53 चलाएं और browse करते समय interface column को monitor करें। प्रत्येक पैकेट wg0 पर होना चाहिए। यदि वे आपके wireless या ethernet interface पर दिखाई देते हैं, तो queries cleartext में बाहर जा रही हैं। dig +short whoami.akamai.net दूसरी जांच देता है, क्योंकि यह उस recursive resolver का public address बताता है जिसने query भेजी थी। इसलिए यदि उत्तर आपके server के address से अलग है, तो leak की पुष्टि होती है।

क्या split tunnel इस्तेमाल करने पर मुझे DNS = line की आवश्यकता है?

हां, और resolver address भी AllowedIPs के अंदर होना चाहिए। अन्यथा क्लाइंट के पास वहां पहुंचने का route नहीं होगा। AllowedIPs = 10.8.0.0/24 के साथ 10.8.0.1 पर मौजूद resolver कवर हो जाता है और query encrypted रहती है। 9.9.9.9 जैसा public resolver कवर नहीं होता। इसलिए query local link से बाहर चली जाती है, भले ही DNS line सही दिखाई दे।

resolvectl सही server दिखाता है, लेकिन lookups फिर भी कहीं और क्यों जाते हैं?

systemd-resolved प्रत्येक link के लिए अलग resolver list रखता है और प्रत्येक query के लिए एक link चुनता है। इसलिए wg0 पर सही entry को अनदेखा किया जाता है, जब किसी दूसरे link पर names के लिए default route मौजूद हो। क्लाइंट के [Interface] block में PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. जोड़ें और DNS = line हटाएं। इसके बाद resolvectl status wg0 को Default Route: yes report करना चाहिए।

कई clients में समस्या होने पर मुझे पहले किस client को ठीक करना चाहिए?

एक Linux client को ठीक करें, क्योंकि यही एकमात्र platform है जो आपको mechanism दिखाता है। resolvectl status और tcpdump बताते हैं कि किस resolver ने उत्तर दिया और packet किस interface से गया। Phone और desktop apps समान DNS और AllowedIPs values लागू करते हैं, लेकिन plumbing दिखाई नहीं देती। इसलिए Linux client सही होने के बाद आप ऐसी configuration कॉपी कर रहे होंगे जिसे आप पहले ही प्रमाणित कर चुके हैं।