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 को इधर-उधर करता है और DNS (domain name system, वह सेवा जो example.com जैसे नामों को IP addresses में बदलती है) के बारे में कुछ नहीं जानता। client [Interface] block में मौजूद DNS = लाइन कोई WireGuard सेटिंग नहीं है। इसे 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 से शुरुआत करें और उसके बाद इस पृष्ठ पर वापस आएँ।

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 में कोई भी बदलाव मदद नहीं करेगा। यदि pings का जवाब आता है लेकिन वास्तविक traffic शुरू होते ही throughput गिर जाता है, तो यह एक अलग तरह की खराबी है, और धीमा WireGuard लगभग हमेशा MTU के कारण होता है, न कि इस पृष्ठ पर दी गई किसी चीज़ के कारण। यहाँ हर उदाहरण में 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 को जानबूझकर सक्रिय रखता है ताकि machine अपने printer तक पहुँच सके। DHCP द्वारा client को मिला resolver, जो आमतौर पर 192.168.1.1 पर स्थित router होता है, उन local routes में से एक से मेल खाता है। आपका traffic tunnel से होकर जाता है, लेकिन local network को उन सभी नामों की पूरी सूची मिल जाती है जिन्हें आप search करते हैं।

दूसरा कारण है 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 print करता है। यदि आपके ethernet या wireless link के block में अभी भी Current DNS Server: 192.168.1.1 दिखाई देता है जबकि wg0 block में कुछ नहीं है, तो यह leak है। dig +short whoami.akamai.net का आपके server के address के बजाय आपके home broadband address को लौटाना इसे दूर से ही confirm कर देता है। 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 चलाने से किसी third party को अपना key material दिए बिना यह coordination मिलती है। यदि आखिरी बात आपको चिंतित करती है, तो ध्यान रखें कि Tailscale आपके traffic को encrypt करने वाली keys कभी अपने पास नहीं रखता। अधिक महत्वपूर्ण प्रश्न यह है कि breached coordination server या चोरी किए गए identity account से आपके network में क्या अतिरिक्त access मिल सकता है।

Failure three: Linux clients पर resolvconf और systemd-resolved के बीच संघर्ष

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

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

resolvconf: command not found

wg-quick, resolvconf को कॉल करता है, और वह binary installed नहीं होती है। systemd-resolved के साथ काम करने वाले implementation को install करें, और फिर 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 होता है और आपके वाले में नहीं।

Resolver को set करें और उसी चरण में 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 को delete कर दें, क्योंकि अन्यथा दो mechanisms resolver state को लिखते हैं और बाद में केवल एक ही उसे clean up करता है। ~. 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 वाला हिस्सा run नहीं हुआ है, और आप वापस link selection पर आ गए हैं।

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

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

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

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

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

यदि क्लाइंट कॉन्फ़िगरेशन में पहले से ही 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 पर होना चाहिए। यदि वे आपके 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 local link के माध्यम से बाहर निकल जाती है, भले ही DNS line सही दिख रही हो।

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

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

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

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