WireGuard DNS పనిచేయకపోతే 3 పరిష్కారాలు

WireGuard టన్నెల్ ప్రారంభమైన వెంటనే DNS ఎందుకు పనిచేయడం ఆగిపోతుంది

DNS over WireGuard మూడు విధాలుగా విఫలమవుతుంది. ప్రతి సమస్యకు ప్రత్యేక పరిష్కారం ఉంటుంది. ఏ పేరూ resolve కాకపోవచ్చు, లేదా పేర్లు resolve అయినా queries టన్నెల్ వెలుపల ఉన్న మీ machine నుంచి బయటకు వెళ్లవచ్చు, లేదా interface ప్రారంభమైన కొన్ని seconds తర్వాత client యొక్క స్వంత resolver manager setting ను తిరిగి రాయవచ్చు. సమస్య సాధారణంగా టన్నెల్‌లో ఉండదు. 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 దాన్ని చదువుతుంది. ఆ తర్వాత టన్నెల్ active గా ఉన్నప్పుడు wg-quick client యొక్క resolver configuration ను మార్చుతుంది. టన్నెల్‌ను wg-quick down పై నిలిపివేసినప్పుడు దానిని మళ్లీ పునరుద్ధరిస్తుంది. కాబట్టి దిగువ సమస్యలన్నీ routing problem లేదా wg-quick problem. అవి cryptography problem కావు. టన్నెల్ ఇంకా నిర్మించకపోతే, ముందుగా మీ స్వంత 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 output లో ఇటీవలి latest handshake తో peer కనిపించాలి. రెండు ping commands కు సమాధానం రావాలి. ping 1.1.1.1 timeout అయితే, అది DNS problem కాదు; forwarding లేదా NAT (network address translation) problem. Resolver config ను ఎన్నిసార్లు మార్చినా అది పరిష్కారం కాదు. ఇక్కడి ప్రతి ఉదాహరణలో టన్నెల్ 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 internet‌కు చేరుతున్నాయని నిర్ధారించవచ్చు. రెండవది ఏదీ తిరిగి ఇవ్వదు మరియు ;; communication timed out; no servers could be reached ను చూపిస్తుంది. కారణం ఇదే: మీ 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 ఉన్న line కనిపిస్తుంది. 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 ఉపయోగిస్తే, 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ను పెంచడానికి ఉపయోగిస్తాయి. ఆ trafficను మీరు గమనించేలోపే మీ provider గుర్తించే అవకాశం ఉంది.

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 అవుతాయి, పేజీలు లోడ్ అవుతాయి. మీరు విశ్వసించకూడదనుకున్న local network మీదుగా queries cleartext‌లో వెళ్తాయి.

దీనికి రెండు configurations కారణమవుతాయి. మొదటిది, AllowedIPs = 0.0.0.0/0, ::/0 ఉన్నా DNS = line లేని client. wg-quick తన స్వంత routing table‌లో default route‌ను install చేస్తుంది. అలాగే suppress_prefixlength 0తో ఒక rule‌ను add చేస్తుంది. దీని వల్ల మరింత specific local routes ఉద్దేశపూర్వకంగా పనిచేస్తూనే ఉంటాయి. అందువల్ల machine తన printer‌ను చేరుకోగలదు. Client DHCP ద్వారా పొందిన 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తో ఉన్న configuration. 9.9.9.9, AllowedIPsలో లేకపోవడం వల్ల client‌కు దాన్ని tunnel ద్వారా చేరుకునే route ఉండదు. అందువల్ల మొదటి సందర్భంలోలాగే query local link ద్వారా బయటకు వెళ్తుంది.

నిజంగా ఏ resolver సమాధానం ఇస్తుందో నిరూపించండి. whoami.akamai.net అనేది 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‌ను print చేస్తుంది. మీ ethernet లేదా wireless link‌కు సంబంధించిన block‌లో ఇంకా Current DNS Server: 192.168.1.1 కనిపిస్తుండగా, wg0 block‌లో ఏదీ కనిపించకపోతే, అదే లీక్. dig +short whoami.akamai.net మీ server address‌కు బదులుగా మీ home broadband address‌ను return చేస్తే, remote end నుంచి కూడా ఇది నిర్ధారితమవుతుంది. వివాదాలకు తుది ఆధారం tcpdump line. సరైన output‌లో ప్రతి port 53 packet wg0 మీదుగా వెళ్తుంది. లీక్ ఉన్నప్పుడు అవి wlan0 లేదా enp3s0 మీదుగా వెళ్తాయి.

దీనికి రెండు భాగాల fix అవసరం. రెండూ తప్పనిసరి. DNSను tunnel‌లో ఉన్న address‌కు set చేయండి. ఆ 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‌గా add చేయండి: 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‌లో భాగం. స్వయంగా నిర్వహించే Headscale control serverను అమలు చేస్తే, మీ key material‌ను third partyకి అప్పగించకుండా ఈ coordination లభిస్తుంది.

వైఫల్యం మూడు: Linux క్లయింట్లలో resolvconf మరియు systemd-resolved పరస్పరం జోక్యం చేసుకోవడం

macOS, Windows, iOS మరియు Android క్లయింట్లు అధికారిక app ద్వారా DNS =ను వర్తింపజేస్తాయి. అందువల్ల సాధారణంగా తక్కువ సమస్యలు వస్తాయి. Linuxలో ఈ settingను shell script ద్వారా వర్తింపజేస్తారు. మీరు ఉపయోగిస్తున్న resolver manager ఏదో ఆ 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 సరిగ్గా కనిపిస్తుంది. అయినప్పటికీ lookups పాత resolverకే వెళ్తాయి. systemd-resolved ప్రతి linkకు ప్రత్యేక resolver listను ఉంచుతుంది. ప్రతి queryకు ఒక linkను ఎంచుకుంటుంది. ఏ linkనూ namesకు default routeగా గుర్తించకపోతే, wireless linkలో search domain ఉన్నందున దాని resolverనే ఉపయోగిస్తుంది. మీ linkలో search domain ఉండదు.

Resolverను సెట్ చేసి, అదే దశలో default routeను claim చేయండి. %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 = 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గా ఉంటే, దానిని మరేదో software నిర్వహిస్తోంది. సాధారణంగా అది NetworkManager లేదా container runtime అవుతుంది. ఇతర debugging చేయడానికి ముందు ls -l /etc/resolv.confను అమలు చేయండి. ప్రతి network మార్పు సమయంలో ఆ fileను తిరిగి రాసే tool ఉంటే, అది అత్యంత అననుకూల సమయంలో మీ మార్పులను రద్దు చేస్తుంది.

టన్నెల్‌పై మీ స్వంత ఫిల్టరింగ్ resolver ను అప్‌గ్రేడ్ చేయడం

క్వెరీలు టన్నెల్ ద్వారా విశ్వసనీయంగా ప్రయాణించిన తర్వాత, దూరపు చివరలో ఉన్న resolver ఒక నియంత్రణ కేంద్రంగా మారుతుంది. అక్కడ AdGuard Home నడిపితే, కనెక్ట్ అయిన ప్రతి పరికరానికి client software లేదా ఒక్కో పరికరానికి ప్రత్యేక కాన్ఫిగరేషన్ అవసరం లేకుండా blocklist filtering మరియు query log లభిస్తాయి. 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పై listening చేస్తుంది. ఆ portను బహిరంగంగా తెరవకుండా, టన్నెల్ ద్వారా http://10.8.0.1:3000 వద్ద దాన్ని యాక్సెస్ చేయండి. Wizardలో DNS listen address మరియు admin listen address రెండింటినీ 10.8.0.1గా సెట్ చేయండి. failure one నుంచి వచ్చిన 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తో exit అవుతుంది.

Client configsలో ఇప్పటికే DNS = 10.8.0.1 ఉంటే ఎలాంటి మార్పు అవసరం లేదు. ఇప్పుడు query log ప్రతి peer నుంచి వచ్చిన ప్రతి lookupను చూపుతుంది. ఇది ఉచిత ప్రయోజనం కాదు; ఇది గోప్యతకు సంబంధించిన వాస్తవ నిర్ణయం. మీరు నమ్మకాన్ని మీ internet provider నుంచి మీవైపు మార్చుతున్నారు. ఆ boxను patch చేసి ఉంచాల్సిన బాధ్యత కూడా మీదే. Internetకు బహిర్గతమైన serverలో ప్రాథమిక భద్రతా ఏర్పాట్లు ముందుగా ఉండాలి. కొత్త VPSలో మొదటి పది నిమిషాలు వాటిని వివరిస్తుంది.

FAQ

నా WireGuard టన్నెల్ కనెక్ట్ అవుతోంది, కానీ పేర్లు ఎందుకు పరిష్కరించబడటం లేదు?

టన్నెల్ ప్యాకెట్లను మాత్రమే తీసుకెళ్తుంది; పేర్లను అసలు నిర్వహించదు. అందువల్ల టన్నెల్ పనిచేస్తూ lookupలు విఫలమైతే, మీరు సూచించిన resolver సమాధానం ఇవ్వడం లేదని అర్థం. క్లయెంట్‌లో dig +short @10.8.0.1 example.com తో పరీక్షించండి. communication timed out సమాధానం అంటే, సాధారణంగా systemd-resolved stub 127.0.0.53 కు మాత్రమే bind కావడం వల్ల ఆ టన్నెల్ చిరునామాలో resolver వినడం లేదో, లేదా wg0 పై వచ్చిన UDP port 53 ను server firewall drop చేస్తోందో అర్థం. ముందుగా listener సమస్యను సరిచేయండి. తర్వాత wg0 కోసం మాత్రమే port ను తెరవండి.

నా DNS WireGuard ద్వారా లీక్ అవుతోందో ఎలా తనిఖీ చేయాలి?

క్లయెంట్‌లో sudo tcpdump -ni any -c 10 port 53 నడిపి, మీరు browse చేస్తున్నప్పుడు interface column ను monitor చేయండి. ప్రతి ప్యాకెట్ wg0 పై ఉండాలి. అవి మీ wireless లేదా ethernet interface పై కనిపిస్తే, queries cleartext గా బయటకు వెళ్తున్నాయి. dig +short whoami.akamai.net తో రెండోసారి నిర్ధారించవచ్చు. అది query చేసిన recursive resolver యొక్క public address తో సమాధానం ఇస్తుంది. మీ server address కాకుండా వేరే 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 ఈ పరిధిలోకి రాదు. అందువల్ల DNS line సరైనదిగా కనిపించినప్పటికీ, query local link ద్వారా బయటకు వెళ్తుంది.

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 చేయాలి.

అనేక క్లయెంట్లు పనిచేయకపోతే ముందుగా ఏ క్లయెంట్‌ను సరిచేయాలి?

ఒక Linux క్లయెంట్‌ను ముందుగా సరిచేయండి. కారణం, mechanism ను చూపించే ఏకైక platform అదే. ఏ resolver సమాధానం ఇచ్చిందో, ప్యాకెట్ ఏ interface ద్వారా వెళ్లిందో resolvectl status మరియు tcpdump తెలియజేస్తాయి. Phone మరియు desktop apps అదే DNS మరియు AllowedIPs values ను ఉపయోగిస్తాయి, కానీ plumbing కనిపించదు. Linux క్లయెంట్ సరిగా పనిచేసిన తర్వాత, మీరు ఇప్పటికే నిర్ధారించిన configuration ను కాపీ చేయవచ్చు.