WireGuard मध्ये DNS बिघाडाचे 3 प्रकार आणि उपाय

WireGuard टनेल सुरू होताच DNS का बिघडते

WireGuard द्वारे DNS तीन प्रकारे अपयशी ठरते. प्रत्येक प्रकारासाठी स्वतंत्र उपाय आहे. काहीही resolve होत नाही. किंवा नावे resolve होतात, पण query टनेलबाहेरून तुमच्या मशीनमधून पाठवल्या जातात. किंवा interface सुरू झाल्यानंतर काही सेकंदांत client चा स्वतःचा resolver manager ही सेटिंग अधिलिखित करतो. टनेल जवळजवळ कधीही समस्येचे कारण नसते. समस्या त्या एका ओळीत असते, जी client ने कोणत्या resolver ला विचारायचे ते सांगते. तसेच त्या resolver कडे packets कोणत्या मार्गाने जातील हे ठरवणाऱ्या routing मध्येही समस्या असू शकते.

WireGuard IP packets पाठवते आणि DNS विषयी त्याला काहीही माहिती नसते. DNS म्हणजे domain name system, जे example.com सारखी नावे IP addresses मध्ये रूपांतरित करते. Client च्या [Interface] block मधील DNS = ओळ ही WireGuard setting नाही. Interface सुरू करणारा shell wrapper wg-quick ही ओळ वाचतो. त्यानंतर wg-quick टनेल सुरू असताना client ची resolver configuration बदलतो आणि wg-quick down वर ती पूर्वस्थितीत आणतो. त्यामुळे खालील प्रत्येक समस्या routing ची किंवा wg-quick ची समस्या आहे. ती cryptography ची समस्या नाही. टनेल अद्याप तयार केलेला नसेल, तर तुमच्या स्वतःच्या VPS वर self-hosted WireGuard VPN पासून सुरुवात करा आणि त्यानंतर या पृष्ठावर परत या.

DNS मध्ये कोणताही बदल करण्यापूर्वी टनेल व्यवस्थित कार्यरत आहे याची खात्री करा.

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 मध्ये कितीही बदल केले तरी त्याचा उपयोग होणार नाही. येथील प्रत्येक उदाहरणात टनेल 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 परत करते. यावरून packets tunnel द्वारे internet पर्यंत पोहोचत असल्याचे सिद्ध होते. दुसरी command काहीही परत करत नाही आणि ;; communication timed out; no servers could be reached छापते. निदान इतकेच आहे: तुमचा client 10.8.0.1 कडे निर्देशित आहे आणि 10.8.0.1 UDP port 53 वर उत्तर देत नाही.

यामागे दोन कारणे असू शकतात. Server वर कोणताही resolver चालू नसतो किंवा server firewall query पोहोचण्यापूर्वी ती टाकून देतो. Server वर दोन्ही तपासा.

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

चालू असलेला आणि योग्यरीत्या bound केलेला 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 कडून जाणूनबुजून unreachable ठेवला जातो. ज्या server वर एकमेव resolver हा stub आहे, त्या server कडे VPN client निर्देशित केल्यास हाच timeout येतो.

यासाठी tunnel address वर listening करणारा 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 साठी कधीही उघडा ठेवू नका. Open recursive resolver scanners ना काही दिवसांत सापडतो आणि denial of service attacks वाढवण्यासाठी वापरला जातो. तुमचा 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 साठी मार्ग ठरवत नाही

ही समस्या अधिक गंभीर आहे, कारण सर्व काही कार्यरत असल्याचे दिसते. नावे resolve होतात, पृष्ठे लोड होतात आणि तुम्ही विश्वास ठेवू इच्छित नसलेल्या स्थानिक नेटवर्कवरून queries cleartext स्वरूपात प्रवास करतात.

यासाठी दोन configurations कारणीभूत असतात. पहिली configuration म्हणजे AllowedIPs = 0.0.0.0/0, ::/0 असलेला आणि DNS = line नसलेला client. wg-quick स्वतःच्या routing table मध्ये default route स्थापित करतो आणि suppress_prefixlength 0 सह rule जोडतो. त्यामुळे अधिक specific local routes जाणूनबुजून कार्यरत राहतात आणि machine ला त्याच्या printer पर्यंत पोहोचता येते. Client ने DHCP द्वारे शिकलेला resolver, सामान्यतः 192.168.1.1 वरील router, या local routes पैकी एका route शी जुळतो. तुमचा traffic tunnel मधून जातो. मात्र local network ला तुम्ही शोधलेल्या नावांची संपूर्ण यादी मिळत राहते.

दुसरी configuration म्हणजे 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 आहे. त्याचे उत्तर query करणाऱ्या recursive resolver चा IP address देते. त्यामुळे तुम्ही त्याचे उत्तर तुमच्या 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 ऐवजी home broadband address परत मिळणे, दूरच्या टोकाकडून याची पुष्टी करते. वाद मिटवणारी खात्री tcpdump line देते: योग्य output मध्ये प्रत्येक port 53 packet 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 आणि coordinated mesh मधील स्पष्ट फरकांपैकी एक आहे. WireGuard ची Tailscale शी तुलना यामध्ये या tradeoff चा भाग आहे. स्वतःचा self-hosted Headscale control server चालवल्याने तुमचे key material third party कडे न देता ही coordination मिळते.

तिसरी अडचण: Linux क्लायंटवर resolvconf आणि systemd-resolved यांच्यात संघर्ष

macOS, Windows, iOS आणि Android क्लायंट अधिकृत app द्वारे DNS = लागू करतात आणि त्यामुळे फारशी अडचण येत नाही. Linux मध्ये ही setting shell script द्वारे लागू केली जाते. त्या script ला तुम्ही अनेक resolver manager पैकी कोणता वापरता, याचा अंदाज घ्यावा लागतो.

पहिली अडचण स्पष्टपणे दिसते. sudo wg-quick up wg0 खालील संदेशासह थांबते:

resolvconf: command not found

wg-quick, resolvconf ला कॉल करते आणि तो binary install केलेला नसतो. systemd-resolved शी संवाद साधणारी implementation install करा. त्यानंतर 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 निवडते. कोणत्याही link ला names साठी default route म्हणून चिन्हांकित केलेले नसल्यास, ते wireless link चा resolver वापरत राहते. कारण त्या link कडे search domain असतो आणि तुमच्या link कडे नसतो.

Resolver सेट करा आणि त्याच step मध्ये 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 ला प्रत्येक 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 असल्यास, ती file दुसऱ्या घटकाच्या नियंत्रणाखाली आहे. सहसा तो घटक NetworkManager किंवा container runtime असतो. इतर कोणतीही तपासणी करण्यापूर्वी ls -l /etc/resolv.conf चालवा. प्रत्येक network change वेळी ती file पुन्हा लिहिणारे tool तुमचे बदल अयोग्य वेळी रद्द करू शकते.

अपग्रेड: टनेलवरून स्वतःचा फिल्टरिंग resolver

क्वेरी विश्वासार्हपणे टनेलमधून जाऊ लागल्यानंतर, दुसऱ्या टोकाला असलेला resolver नियंत्रणबिंदू बनतो. तेथे AdGuard Home चालवल्यास प्रत्येक कनेक्ट केलेल्या उपकरणाला blocklist filtering आणि query log मिळतो. यासाठी client software किंवा प्रत्येक उपकरणाची स्वतंत्र configuration आवश्यक नसते. July 2026 मध्ये तपासलेली अधिकृत install script एकाच ओळीत आहे.

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

पहिल्यांदा चालू केल्यावर setup wizard port 3000 वर ऐकतो. तो port सार्वजनिकपणे उघडण्याऐवजी टनेलद्वारे 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 वर UDP port 53 ला दोन processes bind करू शकत नाहीत आणि दुसरा process listen udp 10.8.0.1:53: bind: address already in use सह बंद होतो.

Client configs मध्ये बदल करण्याची गरज नाही, जर त्यांमध्ये आधीच DNS = 10.8.0.1 असेल. आता query log मध्ये प्रत्येक peer कडून झालेली प्रत्येक lookup दिसेल. हा विनामूल्य लाभ नसून गोपनीयतेबाबतचा वास्तविक निर्णय आहे: विश्वास internet provider कडून स्वतःकडे हलतो आणि त्या box वर patches लागू ठेवण्याची जबाबदारी तुमची असते. Internet समोर उघडलेल्या server वर मूलभूत सुरक्षा उपाय आधी लागू केलेले असणे आवश्यक आहे. नवीन VPS वरील पहिली दहा मिनिटे हे उपाय समाविष्ट करते.

FAQ

माझे WireGuard tunnel कनेक्ट होते, पण नावे का resolve होत नाहीत?

tunnel packets वाहून नेतो; तो नावे हाताळत नाही. त्यामुळे 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 उघडा.

माझा 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 ने query केली त्याचा public address देतो. त्यामुळे तुमच्या server च्या address व्यतिरिक्त दुसरा 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 असेल. client च्या [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 आहे. resolvectl status आणि tcpdump यांद्वारे कोणत्या resolver ने उत्तर दिले आणि packet कोणत्या interface वरून गेला हे समजते. Phone आणि desktop apps हेच DNS आणि AllowedIPs values वापरतात, पण अंतर्गत प्रक्रिया दिसत नाही. त्यामुळे Linux client योग्य झाल्यावर, आधीच सिद्ध केलेली configuration तुम्ही इतरत्र लागू करता.