WireGuard पर DNS काम न करने की 3 मुख्य समस्याएं और समाधान

WireGuard tunnel चालू होते ही DNS क्यों काम करना बंद कर देता है

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

WireGuard IP packets को move करता है और DNS (domain name system, वह service जो example.com जैसे नामों को IP addresses में बदलती है) के बारे में कुछ नहीं जानता। client [Interface] block में मौजूद DNS = लाइन WireGuard की setting नहीं है। इसे wg-quick द्वारा पढ़ा जाता है, जो एक shell wrapper है और interface को up करता है, और फिर wg-quick tunnel के active रहने के दौरान client की resolver configuration को edit करता है और wg-quick down पर उसे restore कर देता है। इसलिए नीचे दी गई हर समस्या एक 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 दिखना चाहिए, और दोनों pings का जवाब आना चाहिए। यदि ping 1.1.1.1 time out हो जाता है, तो संभावना है कि आपको DNS समस्या के बजाय forwarding या NAT (network address translation) की समस्या है, और resolver config बदलने से कोई मदद नहीं मिलेगी। जो firewall ICMP को drop करता है, वह भी समान timeout देता है, इसलिए forwarding rules बदलने से पहले curl -sI https://1.1.1.1 से पुष्टि करें। यदि pings का जवाब आता है लेकिन वास्तविक traffic शुरू होते ही throughput गिर जाता है, तो यह एक अलग समस्या है, और धीमा WireGuard लगभग हमेशा MTU के कारण होता है, न कि इस page पर दी गई किसी चीज़ के कारण। यहाँ हर उदाहरण में tunnel subnet के रूप में 10.8.0.0/24 और server के tunnel address के रूप में 10.8.0.1 का उपयोग किया गया है। अपनी जानकारी के अनुसार इन्हें बदलें।

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

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

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

क्लाइंट से सीधे टनल resolver से पूछें। dig, Ubuntu और Debian पर dnsutils पैकेज से आता है।

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

पहला कमांड एक पता (address) लौटाता है, जो सिद्ध करता है कि पैकेट टनल के माध्यम से इंटरनेट तक पहुँच रहे हैं। दूसरा कुछ नहीं लौटाता और ;; communication timed out; no servers could be reached प्रिंट करता है। यही पूरा निदान है: आपका क्लाइंट 10.8.0.1 पर पॉइंट कर रहा है, और 10.8.0.1 UDP पोर्ट 53 पर उत्तर नहीं दे रहा है।

इसके दो कारण हो सकते हैं। या तो सर्वर पर कोई resolver नहीं चल रहा है, या सर्वर का firewall क्वेरी के पहुँचने से पहले ही उसे ड्रॉप कर रहा है। सर्वर पर दोनों की जाँच करें।

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

जो resolver चल रहा है और सही ढंग से bound है, वह 10.8.0.1:53 या 0.0.0.0:53 के साथ एक लाइन दिखाएगा। Ubuntu पर अक्सर आश्चर्य 127.0.0.53:53 होता है: यह systemd-resolved का stub listener है, जो loopback पते पर bind होता है और अन्य मशीनों से जानबूझकर दुर्गम (unreachable) रखा जाता है। VPN क्लाइंट को ऐसे सर्वर पर पॉइंट करना जिसका एकमात्र resolver वह stub है, ठीक यही timeout उत्पन्न करता है।

इसका समाधान एक ऐसा resolver है जो टनल पते पर listen करे, साथ ही एक firewall नियम जो peers को उस तक पहुँचने दे।

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'

फिर केवल टनल ट्रैफिक के लिए पोर्ट खोलें। nftables के साथ, /etc/nftables.conf में input चेन में ये दो लाइनें जोड़ें और 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 वही काम करता है। पोर्ट 53 को कभी भी सार्वजनिक इंटरनेट के लिए न खोलें। एक open recursive resolver को स्कैनर्स कुछ ही दिनों में ढूंढ लेते हैं और denial of service हमलों को बढ़ाने के लिए उसका उपयोग करते हैं, और आपका प्रदाता आपसे पहले उस ट्रैफिक को नोटिस कर लेगा।

क्लाइंट से dig +short @10.8.0.1 example.com को फिर से चलाएं। आउटपुट में एक पता होने का मतलब है कि resolver पाथ काम कर रहा है, इसलिए क्लाइंट को अब केवल इसका उपयोग करना है। क्लाइंट [Interface] ब्लॉक में लाइन जोड़ें और 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

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

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

दो configurations के कारण ऐसा होता है। पहली है AllowedIPs = 0.0.0.0/0, ::/0 वाला client जिसमें DNS = line नहीं है। wg-quick अपने स्वयं के routing table में default route install करता है और suppress_prefixlength 0 के साथ एक rule जोड़ता है, जो जानबूझकर अधिक विशिष्ट local routes को सक्रिय रखता है ताकि मशीन अभी भी अपने printer तक पहुँच सके। DHCP द्वारा client को मिला resolver, आमतौर पर 192.168.1.1 पर स्थित router, उन local routes में से एक से मेल खाता है। आपका traffic tunnel से होकर जाता है, लेकिन 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 एक public test name है जो उस recursive resolver के IP address के साथ उत्तर देता है जिसने query की थी, ताकि आप उसके उत्तर की तुलना अपने सर्वर के public address से कर सकें।

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

resolvectl status प्रत्येक link के लिए एक block print करता है। यदि आपके ethernet या wireless link के block में अभी भी Current DNS Server: 192.168.1.1 दिखाई देता है जबकि wg0 block में कुछ नहीं है, तो यह leak है। dig +short whoami.akamai.net का आपके सर्वर के address के बजाय आपके home broadband address को लौटाना इसे दूर से ही confirm कर देता है। tcpdump line वह प्रमाण है जो विवादों को समाप्त करता है: स्वस्थ output मशीन से बाहर जाने वाले प्रत्येक port 53 packet को wg0 पर रखता है, और leak होने पर वे wlan0 या enp3s0 पर चले जाते हैं। 127.0.0.53 से या उस तक lo पर जाने वाले packets वे applications हैं जो local systemd-resolved stub से बात कर रहे हैं, और वे leak नहीं हैं।

इस सुधार के दो भाग हैं और दोनों आवश्यक हैं। DNS को एक ऐसे address पर सेट करें जो 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 होती है और सर्वर को भेजी जाती है। यदि आप 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 किसी तीसरे पक्ष को सौंपे। यदि वह अंतिम वाक्यांश आपको चिंतित करता है, तो ध्यान दें कि Tailscale कभी भी उन keys को नहीं रखता जो आपके traffic को encrypt करती हैं, और अधिक महत्वपूर्ण प्रश्न यह है कि एक compromised coordination server या चोरी हुआ identity account आपके network में क्या जोड़ सकता है।

तीसरी विफलता: Linux clients पर resolvconf और systemd-resolved के बीच टकराव

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

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

resolvconf: command not found

wg-quick, resolvconf को कॉल करता है, और वह binary install नहीं होती है। Debian 12 और Ubuntu 24.04 या उसके बाद के संस्करणों पर, resolvconf command जो systemd-resolved से बात करती है, वह systemd-resolved package में आती है, इसलिए उसे install करें और फिर interface को दोबारा up करें। Ubuntu 22.04 में इसके लिए कोई अलग package नहीं है; वहाँ, sudo ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf के साथ compatibility link स्वयं बनाएँ और install वाली line को छोड़ दें।

sudo apt install -y systemd-resolved
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, wg0 को ignore नहीं कर रहा है। ऐसा नाम जो किसी routing domain से मेल नहीं खाता, वह हर उस link के DNS servers पर जाता है जिसे default route माना जाता है, और जिस link में DNS servers हों और कोई route-only domain न हो, वह डिफ़ॉल्ट रूप से एक default route ही गिना जाता है। इसलिए query एक ही समय पर 10.8.0.1 और wireless link के router पर जाती है, और जो उत्तर पहले मिलता है वही मान्य होता है। Router एक hop दूर होता है और आमतौर पर पहले उत्तर देता है, और query किसी भी तरह cleartext में बाहर जा चुकी होती है। Wireless link के अपने search domain के अंतर्गत आने वाले नाम, जैसे कि lan, केवल उसी link पर जाते हैं, क्योंकि सबसे विशिष्ट routing domain को प्राथमिकता मिलती है।

जब wg-quick, systemd के अपने resolvconf wrapper के माध्यम से DNS = लागू करता है, तो यह पहले से ही एक catch-all routing domain के लिए पूछता है, इसलिए यह विफलता मुख्य रूप से तब दिखाई देती है जब कोई अन्य resolvconf implementation या network manager ने सेटिंग लागू की हो। इसे स्पष्ट रूप से सेट करने से अनुमान लगाने की आवश्यकता खत्म हो जाती है।

Resolver को सेट करें और उसी चरण में catch-all routing domain का दावा करें। %i interface के नाम में 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 को लिखते हैं और उनमें से केवल एक ही बाद में उसे साफ करता है। ~. argument सबसे महत्वपूर्ण हिस्सा है: यह wg0 को हर नाम के लिए route-only domain बना देता है, इसलिए systemd-resolved उन नामों को अन्य links पर भेजना बंद कर देता है जो किसी अधिक विशिष्ट domain से मेल नहीं खाते। किसी अन्य link के अपने domain के अंतर्गत आने वाले नाम, जैसे कि lan, अभी भी उसी link पर जाते हैं, जो आमतौर पर local hosts के लिए वांछित व्यवहार है। इसकी पुष्टि करें।

resolvectl status wg0

सही output में DNS Servers: 10.8.0.1 और DNS Domain: ~. शामिल होते हैं। यदि ~. गायब है, तो resolvectl domain वाला हिस्सा नहीं चला है, और wg0 वापस अन्य links के साथ प्रतिस्पर्धा कर रहा है। जाँच के लिए default route flag का उपयोग न करें: यह ~. के बिना भी yes (या systemd version के आधार पर Protocols line पर +DefaultRoute) पढ़ता है, क्योंकि बिना route-only domain वाला link वैसे भी एक default route ही होता है।

एक और स्थिति का उल्लेख करना उचित है। यदि /etc/resolv.conf, /run/systemd/resolve/stub-resolv.conf के symlink के बजाय एक वास्तविक file है, तो इसका स्वामित्व किसी और के पास है, आमतौर पर NetworkManager या container runtime के पास। किसी भी अन्य चीज़ को debug करने से पहले ls -l /etc/resolv.conf चलाएँ, क्योंकि जो tool हर network बदलाव पर उस file को फिर से लिखता है, वह आपके काम को सबसे गलत समय पर undo कर देगा।

अपग्रेड: टनल पर आपका अपना फ़िल्टरिंग रिज़ॉल्वर

जब क्वेरीज़ टनल के माध्यम से विश्वसनीय रूप से जाने लगती हैं, तो दूरस्थ छोर पर स्थित रिज़ॉल्वर एक कंट्रोल पॉइंट बन जाता है। वहाँ AdGuard Home चलाने से प्रत्येक कनेक्टेड डिवाइस को ब्लॉकलिस्ट फ़िल्टरिंग और क्वेरी लॉग की सुविधा मिलती है, जिसके लिए किसी क्लाइंट सॉफ़्टवेयर या प्रति-डिवाइस कॉन्फ़िगरेशन की आवश्यकता नहीं होती। आधिकारिक इंस्टॉल स्क्रिप्ट, जिसे अक्टूबर 2026 में जाँचा गया था, एक लाइन की है।

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

सेटअप विज़ार्ड पहली बार चलने पर पोर्ट 3000 पर लिसन करता है। उस पोर्ट को सार्वजनिक रूप से खोलने के बजाय टनल के माध्यम से http://10.8.0.1:3000 पर इसे एक्सेस करें, और विज़ार्ड में DNS लिसन एड्रेस और एडमिन लिसन एड्रेस दोनों को 10.8.0.1 पर सेट करें। यदि विफलता एक से unbound अभी भी वही एड्रेस रखे हुए है, तो पहले इसे sudo systemctl disable --now unbound के साथ रोकें, क्योंकि दोनों एक ही एड्रेस पर UDP पोर्ट 53 के लिए प्रतिस्पर्धा करेंगे और AdGuard Home listen udp 10.8.0.1:53: bind: address already in use के साथ बंद हो जाएगा।

यदि क्लाइंट कॉन्फ़िगरेशन में पहले से ही DNS = 10.8.0.1 लिखा है, तो उन्हें किसी बदलाव की आवश्यकता नहीं है। क्वेरी लॉग अब हर उस लुकअप को दिखाएगा जो हर पीयर से उस तक पहुँचता है, जब तक कि आप किसी क्लाइंट को लॉगिंग से बाहर न कर दें। यह एक वास्तविक गोपनीयता निर्णय है, न कि कोई मुफ्त लाभ: आप अपने इंटरनेट प्रदाता से अपना भरोसा खुद पर स्थानांतरित करते हैं, और आपको ही उस बॉक्स को पैच रखना होगा। इंटरनेट के लिए एक्सपोज़ किए गए सर्वर पर सबसे पहले बुनियादी सुरक्षा उपाय होने चाहिए, और नए VPS पर शुरुआती दस मिनट में उन्हें कवर किया गया है।

FAQ

WireGuard tunnel connect होने के बाद भी names resolve क्यों नहीं होते?

Tunnel केवल packets ले जाता है, यह names को handle नहीं करता है। यदि tunnel काम कर रहा है लेकिन lookups विफल हो रहे हैं, तो इसका मतलब है कि जिस resolver का आप उपयोग कर रहे हैं, वह उत्तर नहीं दे रहा है। Client से dig +short @10.8.0.1 example.com के साथ परीक्षण करें। communication timed out का उत्तर मिलने का मतलब है कि या तो उस tunnel address पर कोई resolver listening नहीं है (अक्सर इसलिए क्योंकि systemd-resolved stub केवल 127.0.0.53 पर bind होता है), या server firewall wg0 पर आने वाले UDP port 53 को drop कर रहा है। पहले listener को ठीक करें, फिर केवल wg0 के लिए port खोलें।

मैं यह कैसे जाँचूँ कि मेरा DNS, WireGuard पर leak हो रहा है या नहीं?

Client पर sudo tcpdump -ni any -c 10 port 53 चलाएँ और browse करते समय interface column पर नज़र रखें। मशीन से बाहर जाने वाला प्रत्येक packet wg0 पर होना चाहिए; lo से या 127.0.0.53 तक जाने वाले packets स्थानीय systemd-resolved stub हैं और वे ठीक हैं। यदि वे आपके 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 के भीतर होना चाहिए, अन्यथा client के पास उस तक पहुँचने का कोई route नहीं होगा। AllowedIPs = 10.8.0.0/24 के साथ, 10.8.0.1 पर स्थित resolver कवर हो जाता है और query encrypted रहती है। 9.9.9.9 जैसा public resolver कवर नहीं होता है, इसलिए query स्थानीय link के माध्यम से बाहर चली जाती है, भले ही DNS line सही दिख रही हो।

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

systemd-resolved एक ऐसा नाम जो किसी routing domain से मेल नहीं खाता, उसे एक साथ सभी default-route links पर भेजता है, जिसमें wg0 भी शामिल है, और पहला सफल उत्तर लौटाता है, जो आमतौर पर स्थानीय router से आता है। Client के [Interface] block में PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. जोड़ें और DNS = line को हटा दें। इसके बाद resolvectl status wg0 को DNS Domain: ~. रिपोर्ट करना चाहिए, और हर वह नाम जिसे कोई अन्य link अधिक विशिष्ट domain के साथ दावा नहीं करता है, वह केवल wg0 पर जाएगा।

जब कई clients खराब हों, तो मुझे सबसे पहले किसे ठीक करना चाहिए?

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