Jinsi ya kurekebisha DNS inayofeli kwenye WireGuard

Kwa nini DNS inafeli mara tu WireGuard tunnel inapowaka

DNS kupitia WireGuard inafeli kwa njia tatu, na kila moja ina suluhisho lake. Aidha majina hayatafsiriwi kabisa, au majina yanatafsiriwa lakini maombi yanatoka nje ya tunnel, au meneja wa resolver wa mteja anafuta usanidi huo sekunde chache baada ya interface kuanza. Tatizo si tunnel yenyewe. Tatizo ni mstari mmoja unaomwambia mteja ni resolver ipi ya kuuliza, na routing inayoamua jinsi pakiti zinavyoelekea kwenye resolver hiyo.

WireGuard husafirisha IP packets na haijui chochote kuhusu DNS (domain name system, huduma inayobadilisha majina kama example.com kuwa anwani za IP). Mstari wa DNS = ndani ya block ya [Interface] ya mteja si usanidi wa WireGuard. Unasomwa na wg-quick, shell wrapper inayowasha interface, na wg-quick kisha huhariri usanidi wa resolver wa mteja wakati tunnel ikiwa hai na kuurejesha katika hali yake ya awali wakati wa wg-quick down. Kwa hivyo kila tatizo hapa chini ni tatizo la routing au tatizo la wg-quick, kamwe si tatizo la cryptography. Ikiwa tunnel yenyewe bado haijajengwa, anza na WireGuard VPN inayojiendesha kwenye VPS yako mwenyewe na urudi kwenye ukurasa huu baadaye.

Thibitisha kuwa tunnel iko salama kabla ya kugusa DNS yoyote.

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

wg show inapaswa kuonyesha peer yenye latest handshake ya hivi karibuni, na pings zote mbili zinapaswa kujibu. Ikiwa ping 1.1.1.1 inagoma (times out), una tatizo la forwarding au NAT (network address translation) badala ya tatizo la DNS, na hakuna kiasi chochote cha usanidi wa resolver kitakachosaidia. Kila mfano hapa unatumia 10.8.0.0/24 kama tunnel subnet na 10.8.0.1 kama anwani ya tunnel ya seva. Badilisha na anwani zako mwenyewe.

Hitilafu ya kwanza: hakuna kinachotatuliwa, kwa sababu resolver haijibu kamwe

Dalili ni dhahiri. ping 1.1.1.1 inafanya kazi, na curl https://example.com inarejesha hivi:

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

Uliza resolver ya tunnel moja kwa moja kutoka kwa client. dig inapatikana kwenye kifurushi cha dnsutils katika Ubuntu na Debian.

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

Amri ya kwanza inarejesha anwani, jambo linalothibitisha kuwa pakiti zinafika kwenye Internet kupitia tunnel. Ya pili hairejeshi chochote na inachapisha ;; communication timed out; no servers could be reached. Hiyo ndiyo utambuzi mzima: client yako imeelekezwa kwenye 10.8.0.1, na 10.8.0.1 haijibu kwenye port ya UDP 53.

Sababu mbili husababisha hili. Aidha hakuna resolver inayofanya kazi kwenye seva, au firewall ya seva inakataa ombi kabla halijafika. Angalia yote mawili kwenye seva.

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

Resolver inayofanya kazi na iliyofungwa kwa usahihi inaonyesha mstari wenye 10.8.0.1:53 au 0.0.0.0:53. Kwenye Ubuntu, mshangao mara nyingi ni 127.0.0.53:53: huyo ni stub listener wa systemd-resolved, ambayo hufunga anwani ya loopback na kwa makusudi haiwezi kufikiwa kutoka kwa mashine nyingine. Kuelekeza VPN client kwenye seva ambayo resolver yake pekee ni stub hiyo husababisha timeout hii hasa.

Suluhisho ni resolver inayosikiliza kwenye anwani ya tunnel, pamoja na sheria moja ya firewall inayoruhusu peers kuifikia.

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'

Kisha fungua port kwa ajili ya trafiki ya tunnel pekee. Ukitumia nftables, ongeza mistari hii miwili kwenye chain ya input katika /etc/nftables.conf na uipakie upya kwa sudo systemctl reload nftables.

udp dport 53 iifname "wg0" accept
tcp dport 53 iifname "wg0" accept

Ukitumia ufw, sudo ufw allow in on wg0 to any port 53 inafanya kazi hiyo hiyo. Usifungue kamwe port 53 kwa Internet ya umma. Resolver ya recursive iliyo wazi hugunduliwa na skana ndani ya siku chache na kutumiwa kukuza mashambulizi ya denial of service, na mtoa huduma wako atagundua trafiki hiyo kabla yako.

Endesha tena dig +short @10.8.0.1 example.com kutoka kwa client. Anwani katika matokeo inamaanisha kuwa njia ya resolver inafanya kazi, kwa hivyo client sasa inabidi tu kuitumia. Ongeza mstari kwenye block ya [Interface] ya client na uanzishe upya interface kwa 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

Hitilafu ya pili: DNS leaks, kwa sababu split tunnel haielekezi resolver

Hii ni mbaya zaidi, kwa sababu kila kitu kinaonekana kufanya kazi. Majina yanatatuliwa, kurasa zinapakia, na maombi yanasafiri kwa maandishi wazi (cleartext) kupitia mtandao wa ndani ambao hukutaka kuuamini.

Usanidi mbili husababisha hili. Wa kwanza ni mteja aliye na AllowedIPs = 0.0.0.0/0, ::/0 na bila mstari wa DNS =. wg-quick huweka default route kwenye jedwali lake la routing na kuongeza sheria yenye suppress_prefixlength 0, ambayo huweka routes mahususi za ndani zikiwa hai kwa makusudi ili mashine iweze bado kufikia printa yake. Resolver ambayo mteja aliipata kupitia DHCP, kwa kawaida ni router iliyo kwenye 192.168.1.1, inalingana na mojawapo ya routes hizo za ndani. Trafiki yako inapita kwenye tunnel. Mtandao wa ndani bado unapokea orodha kamili ya majina unayotafuta.

Wa pili ni split tunnel: AllowedIPs = 10.8.0.0/24 yenye DNS = 9.9.9.9. Kwa sababu 9.9.9.9 haipo ndani ya AllowedIPs, mteja hana route ya kuifikia kupitia tunnel, kwa hivyo ombi linaondoka kupitia link ya ndani kama ilivyo katika kisa cha kwanza.

Thibitisha ni resolver ipi inayojibu kweli. whoami.akamai.net ni jina la majaribio ya umma ambalo hujibu kwa anwani ya IP ya recursive resolver iliyouliza, ili uweze kulinganisha jibu lake na anwani ya umma ya seva yako.

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

resolvectl status huchapisha block moja kwa kila link. Ikiwa block ya ethernet au wireless link yako bado inaonyesha Current DNS Server: 192.168.1.1 wakati block ya wg0 haionyeshi chochote, huo ndio uvujaji. dig +short whoami.akamai.net ikirejesha anwani yako ya broadband ya nyumbani badala ya anwani ya seva yako inathibitisha hilo kutoka upande wa mbali. Mstari wa tcpdump ndio uthibitisho unaomaliza mabishano: matokeo mazuri huweka kila pakiti ya port 53 kwenye wg0, na uvujaji huiweka kwenye wlan0 au enp3s0.

Urekebishaji una sehemu mbili na zote zinahitajika. Weka DNS kwenye anwani iliyo ndani ya tunnel, na uhakikishe kuwa anwani hiyo iko ndani ya 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 inakaa ndani ya 10.8.0.0/24, kwa hivyo ombi linasimbwa kwa njia fiche na kutumwa kwa seva. Ikiwa unasisitiza kutumia resolver ya umma kwenye split tunnel, iongeze kama host route: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Pakiti hizo hupitishwa kwenye tunnel, ingawa mtandao wa ndani bado unaweza kuona kuwa ulichagua mtoa huduma huyo kutoka kwa vipindi vya awali. Resolver unayojiendeshea mwenyewe huepuka swali hili.

Ugawaji wa resolver ni mojawapo ya tofauti zinazoonekana kati ya WireGuard iliyoundwa kwa mikono na mesh iliyoratibiwa. Hii ni sehemu ya tradeoff katika WireGuard ikilinganishwa na Tailscale. Kuendesha seva ya udhibiti ya Headscale inayojihudumia hukupa uratibu huo bila kukabidhi key material yako kwa third party. Ikiwa kipengele hicho cha mwisho ndicho kinachokutia wasiwasi, kumbuka kwamba Tailscale haihifadhi keys zinazoficha traffic yako, na swali muhimu zaidi ni nini server ya uratibu iliyovamiwa au akaunti ya utambulisho iliyoibwa inaweza kuongeza kwenye mtandao wako.

Hitilafu ya tatu: resolvconf na systemd-resolved kugongana kwenye wateja wa Linux

Wateja wa macOS, Windows, iOS na Android hutumia DNS = kupitia programu rasmi na hawana matatizo mengi. Kwenye Linux, mpangilio huu hutumiwa na shell script inayopaswa kubahatisha ni kipi kati ya meneja wa resolver kadhaa unachotumia.

Hitilafu ya kwanza ni ya wazi. sudo wg-quick up wg0 husimama na kuonyesha:

resolvconf: command not found

wg-quick huita resolvconf, na binary hiyo haijasakinishwa. Sakinisha utekelezaji unaowasiliana na systemd-resolved, kisha uwashe kiolesura (interface) tena.

sudo apt install -y openresolv
sudo systemctl restart systemd-resolved
sudo wg-quick down wg0 && sudo wg-quick up wg0
resolvectl status wg0

Hitilafu ya pili ni ya kimya, na ndiyo inayokugharimu jioni nzima. Kiolesura huwaka, resolvectl status wg0 huonyesha DNS Servers: 10.8.0.1 kwa usahihi, lakini utafutaji (lookups) bado unaenda kwenye resolver ya zamani. systemd-resolved huweka orodha tofauti ya resolver kwa kila link na huchagua link kwa kila ombi. Isipokuwa link moja iwekwe kama njia chaguo-msingi (default route) ya majina, itaendelea kutumia resolver ya wireless link, kwa sababu link hiyo ina search domain na yako haina.

Weka resolver na udai njia chaguo-msingi katika hatua moja. %i hupanuka na kuwa jina la kiolesura, kwa hivyo block hii hufanya kazi bila kubadilishwa kwenye kiolesura chochote.

[Interface]
Address = 10.8.0.2/32
PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~.
PostDown = resolvectl revert %i

Futa mstari wa DNS = unapotumia PostUp kwa njia hii, kwa sababu vinginevyo mifumo miwili itaandika hali ya resolver na ni mmoja tu atakayesafisha baadaye. Hoja ya ~. ndiyo nusu muhimu: inaweka wg0 kama routing domain kwa kila jina, kwa hivyo systemd-resolved hutuma maombi yote huko badala ya kuchagua link kwa kila ombi. Ithibitishe.

resolvectl status wg0

Matokeo mazuri (healthy output) yana DNS Servers: 10.8.0.1 na Default Route: yes. Ikiwa Default Route inasomeka no, nusu ya resolvectl domain haikufanya kazi, na umerudi kwenye kuchagua link.

Kuna kisa kingine kinachostahili kutajwa. Ikiwa /etc/resolv.conf ni faili halisi badala ya symlink kwenda /run/systemd/resolve/stub-resolv.conf, kitu kingine kinaimiliki, kwa kawaida ni NetworkManager au container runtime. Endesha ls -l /etc/resolv.conf kabla ya kutatua tatizo lingine lolote, kwa sababu zana inayobadilisha faili hiyo kila mtandao unapobadilika itafuta kazi yako wakati usiofaa zaidi.

Uboreshaji: resolver yako ya kuchuja kupitia tunnel

Mara tu maombi yanaposafiri kwa uhakika kupitia tunnel, resolver iliyo mwisho wa pili inakuwa kituo cha udhibiti. Kuendesha AdGuard Home huko kunapa kila kifaa kilichounganishwa uwezo wa kuchuja kupitia blocklist na kumbukumbu ya maombi (query log), bila kuhitaji programu yoyote kwenye kifaa au usanidi wa kila kifaa. Hati rasmi ya usakinishaji, iliyokaguliwa Julai 2026, ni mstari mmoja.

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

Mchawi wa usanidi (setup wizard) husikiliza kwenye port 3000 wakati wa uendeshaji wa kwanza. Ifikie kupitia tunnel kwa http://10.8.0.1:3000 badala ya kufungua port hiyo hadharani, na kwenye mchawi huo weka anwani ya kusikiliza ya DNS na anwani ya kusikiliza ya admin zote kuwa 10.8.0.1. Ikiwa unbound kutoka kwa hitilafu ya kwanza bado inashikilia anwani hiyo hiyo, iache kwanza kwa kutumia sudo systemctl disable --now unbound, kwa sababu michakato miwili haiwezi kufunga (bind) port 53 ya UDP kwenye anwani moja na mchakato wa pili utaacha kufanya kazi kwa listen udp 10.8.0.1:53: bind: address already in use.

Usanidi wa wateja hauhitaji mabadiliko ikiwa tayari unasema DNS = 10.8.0.1. Kumbukumbu ya maombi sasa itaonyesha kila utafutaji kutoka kwa kila peer, ambayo ni uamuzi halisi wa faragha badala ya faida ya bure: unahamisha imani kutoka kwa mtoa huduma wako wa intaneti kwenda kwako mwenyewe, na wewe ndiye unayepaswa kuhakikisha seva hiyo inasasishwa (patched). Seva iliyo wazi kwenye intaneti inahitaji mambo ya msingi kuwekwa kwanza, na dakika kumi za kwanza kwenye VPS mpya inashughulikia hayo.

FAQ

Kwa nini tunnel yangu ya WireGuard inaunganisha lakini majina hayatafsiriki?

Tunnel hubeba pakiti na haishughulikii majina hata kidogo, kwa hivyo tunnel inayofanya kazi huku utafutaji ukifeli inamaanisha resolver unayoelekeza haijibu. Jaribu kwa kutumia dig +short @10.8.0.1 example.com kutoka kwa mteja. Jibu la communication timed out linamaanisha hakuna resolver inayosikiliza kwenye anwani hiyo ya tunnel, mara nyingi kwa sababu stub ya systemd-resolved hufungwa kwenye 127.0.0.53 pekee, au firewall ya seva inakataa UDP port 53 inayofika kwenye wg0. Rekebisha msikilizaji kwanza, kisha fungua port hiyo kwa ajili ya wg0 pekee.

Ninawezaje kuangalia kama DNS yangu inavuja kupitia WireGuard?

Endesha sudo tcpdump -ni any -c 10 port 53 kwenye mteja na uangalie safu ya interface unapovinjari. Kila pakiti inapaswa kuwa kwenye wg0. Ikiwa zitaonekana kwenye interface yako ya wireless au ethernet, maombi hayo yanatoka bila encryption. dig +short whoami.akamai.net inatoa maoni ya pili, kwa sababu inajibu kwa anwani ya umma ya resolver yoyote ya recursive iliyouliza, kwa hivyo jibu ambalo si anwani ya seva yako linathibitisha uvujaji.

Je, ninahitaji mstari wa DNS = nikitumia split tunnel?

Ndiyo, na anwani ya resolver lazima pia iwe ndani ya AllowedIPs vinginevyo mteja hatakuwa na njia ya kuifikia. Kwa AllowedIPs = 10.8.0.0/24, resolver iliyo kwenye 10.8.0.1 inafunikwa na ombi linasimbwa kwa njia fiche. Resolver ya umma kama 9.9.9.9 haijafunikwa, kwa hivyo ombi linatoka kupitia link ya ndani ingawa mstari wa DNS unaonekana kuwa sahihi.

Kwa nini resolvectl inaonyesha seva sahihi lakini utafutaji bado unaenda kwingine?

systemd-resolved huweka orodha moja ya resolver kwa kila link na huchagua link kwa kila ombi, kwa hivyo ingizo sahihi kwenye wg0 hupuuzwa wakati link nyingine inashikilia njia chaguo-msingi ya majina. Ongeza PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. kwenye block ya [Interface] ya mteja na uondoe mstari wa DNS =. resolvectl status wg0 inapaswa kisha kuripoti Default Route: yes.

Ni mteja yupi ninayepaswa kurekebisha kwanza wakati kadhaa wameharibika?

Rekebisha mteja mmoja wa Linux, kwa sababu ndiyo jukwaa pekee linalokuonyesha utaratibu. resolvectl status na tcpdump zinakuambia ni resolver ipi iliyojibu na ni interface ipi iliyobeba pakiti. Programu za simu na desktop hutumia thamani zilezile za DNS na AllowedIPs bila kuonyesha mfumo wa ndani, kwa hivyo mteja wa Linux akiwa sahihi, unakuwa unanakili usanidi ambao tayari umethibitisha.