Rekebisha DNS ya WireGuard: matatizo 3

Kwa nini DNS huvurugika mara tu handaki la WireGuard linapoanzishwa

DNS kupitia WireGuard hushindwa kwa njia tatu, na kila moja ina suluhisho lake. Huenda hakuna jina linalotatuliwa kabisa, au majina yanatatuliwa lakini hoja zinaondoka kwenye kompyuta yako nje ya handaki, au kidhibiti cha utatuzi cha mteja kinaandika upya mipangilio hiyo sekunde chache baada ya kiolesura kuanza. Handaki lenyewe karibu kamwe si tatizo. Tatizo ni mstari unaomwambia mteja ni kitatua kipi cha kuuliza, pamoja na uelekezaji unaoamua jinsi pakiti zinavyosafiri hadi kwa kitatua hicho.

WireGuard husafirisha pakiti za IP na haijui chochote kuhusu DNS (domain name system, huduma inayobadilisha majina kama example.com kuwa anwani za IP). Mstari wa DNS = katika kizuizi cha mteja cha [Interface] si mpangilio wa WireGuard. Husomwa na wg-quick, kifuniko cha shell kinachowasha kiolesura, na wg-quick hubadilisha usanidi wa kitatua wa mteja wakati handaki linafanya kazi kisha kuurejesha kwenye wg-quick down. Kwa hiyo, kila tatizo lililo hapa chini ni tatizo la uelekezaji au tatizo la wg-quick, kamwe si tatizo la kriptografia. Ikiwa handaki lenyewe bado halijaundwa, anza na VPN ya WireGuard inayojipangisha kwenye VPS yako mwenyewe kisha urudi kwenye ukurasa huu.

Thibitisha kuwa handaki linafanya kazi vizuri kabla hujagusa DNS.

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

wg show inapaswa kuorodhesha rika lenye latest handshake ya hivi karibuni, na ping zote mbili zinapaswa kujibu. Ikiwa ping 1.1.1.1 itaisha muda, una tatizo la uelekezaji wa mbele au NAT (network address translation), si tatizo la DNS, na hakuna kiasi cha usanidi wa kitatua kitakachosaidia. Kila mfano hapa unatumia 10.8.0.0/24 kama subneti ya handaki na 10.8.0.1 kama anwani ya handaki ya seva. Badilisha kwa thamani zako mwenyewe.

Kushindwa kwa kwanza: hakuna kinachotatuliwa, kwa sababu resolver haijibu kamwe

Dalili ni wazi. ping 1.1.1.1 inafanya kazi, na curl https://example.com inarudisha:

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

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

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

Amri ya kwanza inarudisha anwani. Hii inathibitisha kuwa pakiti zinafika kwenye intaneti kupitia tunnel. Amri ya pili hairudishi chochote na kuchapisha ;; communication timed out; no servers could be reached. Huo ndio utambuzi kamili: client yako imeelekezwa kwenye 10.8.0.1, na 10.8.0.1 haijibu kwenye UDP port 53.

Sababu mbili husababisha hali hii. Huenda hakuna resolver inayoendesha kwenye server, au firewall ya server inatupa ombi kabla halijafika. Kagua yote mawili kwenye server.

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

Resolver inayoendesha na kufungwa kwa usahihi huonyesha mstari wenye 10.8.0.1:53 au 0.0.0.0:53. Kwenye Ubuntu, mshangao kwa kawaida ni 127.0.0.53:53. Hii ni systemd-resolved stub listener, inayofunga anwani ya loopback na ambayo haiwezi kufikiwa kimakusudi kutoka kwa mashine nyingine. Kuelekeza VPN client kwenye server 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 hiyo kwa traffic ya tunnel pekee. Kwa kutumia nftables, ongeza mistari hii miwili kwenye chain ya input katika /etc/nftables.conf, kisha upakie upya kwa sudo systemctl reload nftables.

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

Kwa ufw, sudo ufw allow in on wg0 to any port 53 hufanya kazi hiyo hiyo. Usifungue port 53 kwa intaneti ya umma kamwe. Recursive resolver iliyo wazi hugunduliwa na scanners ndani ya siku chache na kutumiwa kukuza mashambulizi ya denial of service. Mtoa huduma wako ataona traffic 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, hivyo client sasa inahitaji kuitumia tu. Ongeza mstari huo kwenye block ya client [Interface], kisha 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 inavuja, kwa sababu split tunnel haipitishi seva ya kutatua majina

Hii ni mbaya zaidi, kwa sababu kila kitu huonekana kufanya kazi. Majina hutatuliwa, kurasa hupakiwa, na maulizo husafiri bila usimbaji kwenye mtandao wa ndani ambao hukutaka kuuamini.

Mipangilio miwili husababisha hali hii. Wa kwanza ni mteja mwenye AllowedIPs = 0.0.0.0/0, ::/0 bila mstari wa DNS =. wg-quick huweka njia chaguo-msingi katika jedwali lake la uelekezaji na huongeza kanuni yenye suppress_prefixlength 0. Hii huacha njia za ndani zilizo mahususi zaidi ziendelee kufanya kazi ili mashine iweze bado kufikia printa yake. Seva ya kutatua majina ambayo mteja alipata kupitia DHCP, kwa kawaida router iliyo kwenye 192.168.1.1, inalingana na mojawapo ya njia hizo za ndani. Trafiki yako hupitia tunnel. Mtandao wa ndani bado hupokea 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 haimo ndani ya AllowedIPs, mteja hauna njia ya kuifikia kupitia tunnel. Kwa hiyo, maulizo hutoka kupitia kiungo cha ndani, kama ilivyo katika hali ya kwanza.

Thibitisha ni seva ipi ya kutatua majina inayojibu kwa kweli. whoami.akamai.net ni jina la jaribio la umma ambalo hujibu kwa anwani ya IP ya seva ya recursive resolver iliyoanzisha ombi. Hivyo, unaweza 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 kizuizi kimoja kwa kila kiungo. Ikiwa kizuizi cha kiungo chako cha ethernet au wireless bado kinaonyesha Current DNS Server: 192.168.1.1, huku kizuizi cha wg0 hakionyeshi chochote, huo ndio uvujaji. dig +short whoami.akamai.net inaporejesha anwani yako ya broadband ya nyumbani badala ya anwani ya seva yako, hilo huthibitisha uvujaji kutoka upande wa mbali. Mstari wa tcpdump ndio uthibitisho wa mwisho: katika hali salama, kila pakiti ya port 53 hupitia wg0, na katika hali yenye uvujaji hupitia wlan0 au enp3s0.

Marekebisho yana sehemu mbili, na zote zinahitajika. Weka DNS kwenye anwani iliyo ndani ya tunnel, na uhakikishe kuwa anwani hiyo imo 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 imo ndani ya 10.8.0.0/24, kwa hiyo ombi linasimbwa na kutumwa kwenye 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 zitatumwa kupitia tunnel, ingawa mtandao wa ndani bado unaweza kuona kuwa ulichagua mtoa huduma huyo kutokana na vipindi vya awali. Resolver unayoiendesha mwenyewe huondoa suala hilo.

Ugawaji wa resolver ni mojawapo ya tofauti zinazoonekana kati ya WireGuard iliyoundwa kwa mkono na mesh iliyoratibiwa. Hii ni sehemu ya mabadilishano yaliyo katika WireGuard ikilinganishwa na Tailscale. Kuendesha seva ya udhibiti ya Headscale inayojihudumia hukupa uratibu huo bila kukabidhi key material yako kwa mtu mwingine.

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

Wateja wa macOS, Windows, iOS na Android hutumia DNS = kupitia programu rasmi na husababisha matatizo machache. Linux ndiyo yenye tatizo, kwa sababu mpangilio huo hutumiwa na hati ya shell inayopaswa kukisia ni kipi kati ya vidhibiti kadhaa vya resolver unachotumia.

Hitilafu ya kwanza hujitokeza wazi. sudo wg-quick up wg0 husimama ikiwa na ujumbe huu:

resolvconf: command not found

wg-quick huita resolvconf, lakini faili hilo la binary halijasakinishwa. Sakinisha utekelezaji unaowasiliana na systemd-resolved, kisha iwashe 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 haitoi ujumbe, na ndiyo inayoweza kupoteza jioni nzima. Interface huwashwa, resolvectl status wg0 huonyesha kwa usahihi DNS Servers: 10.8.0.1, lakini utafutaji bado huenda kwa resolver ya zamani. systemd-resolved huhifadhi orodha tofauti ya resolver kwa kila link na huchagua link kwa kila swali. Isipokuwa link moja iwekwe kuwa njia chaguo-msingi ya majina, itaendelea kutumia resolver ya link isiyotumia waya, kwa sababu link hiyo ina search domain na yako haina.

Weka resolver na utangaze njia chaguo-msingi katika hatua moja. %i hubadilishwa kuwa jina la interface, kwa hiyo block hii hufanya kazi bila mabadiliko kwenye interface yoyote.

[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 la sivyo mifumo miwili itaandika hali ya resolver na mmoja tu kati yao atasafisha baadaye. Kigezo cha ~. ndicho sehemu muhimu: huweka wg0 kuwa routing domain ya kila jina, kwa hiyo systemd-resolved hutuma maswali yote huko badala ya kuchagua link kwa kila swali. Ihakikishe.

resolvectl status wg0

Matokeo sahihi yana DNS Servers: 10.8.0.1 na Default Route: yes. Ikiwa Default Route inasoma no, sehemu ya resolvectl domain haikutekelezwa, na umerudi kwenye uteuzi wa link.

Kuna hali nyingine inayofaa kutajwa. Ikiwa /etc/resolv.conf ni faili halisi badala ya symlink inayoelekea /run/systemd/resolve/stub-resolv.conf, kitu kingine ndicho kinachoimiliki, kwa kawaida NetworkManager au runtime ya container. Tekeleza ls -l /etc/resolv.conf kabla ya kuchunguza jambo lingine, kwa sababu zana inayoandika upya faili hilo kila mabadiliko ya mtandao yanapotokea itafuta kazi yako wakati usiofaa zaidi.

Uboreshaji: resolver yako ya kuchuja kupitia tunnel

Baada ya maulizo kusafiri kwa kutegemewa kupitia tunnel, resolver iliyo upande wa mbali huwa sehemu ya udhibiti. Kuendesha AdGuard Home huko huwezesha kila kifaa kilichounganishwa kutumia uchujaji wa blocklist na kumbukumbu ya maulizo, bila programu ya mteja wala 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 husikiliza kwenye port 3000 wakati wa kuanza kwa mara ya kwanza. Ufikie kupitia tunnel kwa http://10.8.0.1:3000 badala ya kufungua port hiyo hadharani, kisha katika mchawi weka anwani ya kusikiliza ya DNS na anwani ya kusikiliza ya msimamizi zote ziwe 10.8.0.1. Ikiwa unbound kutoka kwenye hitilafu ya kwanza bado inatumia anwani hiyo hiyo, isimamishe kwanza kwa sudo systemctl disable --now unbound, kwa sababu michakato miwili haiwezi kufunga UDP port 53 kwenye anwani moja na mchakato wa pili hutoka kwa listen udp 10.8.0.1:53: bind: address already in use.

Mipangilio ya wateja haihitaji mabadiliko ikiwa tayari ina DNS = 10.8.0.1. Kumbukumbu ya maulizo sasa itaonyesha kila utafutaji kutoka kwa kila peer. Hili ni uamuzi halisi kuhusu faragha, si faida ya bila gharama: unahamisha uaminifu kutoka kwa mtoa huduma wako wa intaneti kwenda kwako mwenyewe, na wewe ndiye unayepaswa kuhakikisha kuwa seva hiyo inapata viraka vya usalama. Seva iliyo wazi kwa intaneti inahitaji misingi iwekwe kwanza, na dakika kumi za kwanza kwenye VPS mpya inaieleza.

FAQ

Kwa nini tunnel yangu ya WireGuard inaunganishwa lakini majina hayasuluhishwi?

Tunnel hubeba pakiti na haishughulikii majina kabisa. Kwa hiyo, tunnel inayofanya kazi pamoja na utafutaji uliovurugika humaanisha kuwa resolver unayoelekeza kwake hajibu. Fanya jaribio kwa dig +short @10.8.0.1 example.com kutoka kwa mteja. Jibu la communication timed out humaanisha kwamba hakuna resolver anayesikiliza kwenye anwani hiyo ya tunnel, mara nyingi kwa sababu stub ya systemd-resolved inafungamana na 127.0.0.53 pekee, au firewall ya seva inatupa pakiti za UDP port 53 zinazoingia kupitia wg0. Rekebisha msikilizaji kwanza, kisha fungua port hiyo kwa wg0 pekee.

Ninaangaliaje ikiwa DNS yangu inavuja kupitia WireGuard?

Endesha sudo tcpdump -ni any -c 10 port 53 kwenye mteja na ufuatilie safu ya interface unapovinjari. Kila pakiti inapaswa kuwa kwenye wg0. Ikiwa zinaonekana kwenye interface yako ya wireless au ethernet, maulizo yanaondoka bila usimbaji. dig +short whoami.akamai.net hutoa uthibitisho wa pili, kwa sababu hujibu kwa anwani ya umma ya recursive resolver aliyeuliza. Kwa hiyo, jibu ambalo si anwani ya seva yako linathibitisha uvujaji.

Je, ninahitaji mstari wa DNS = ikiwa natumia split tunnel?

Ndiyo, na anwani ya resolver lazima pia iwe ndani ya AllowedIPs. La sivyo, mteja hana njia ya kuifikia. Ukiwa na AllowedIPs = 10.8.0.0/24, resolver aliye kwenye 10.8.0.1 anahusika na maulizo husimbwa kwa njia fiche. Resolver wa umma kama 9.9.9.9 hahusiki, kwa hiyo ombi huondoka kupitia kiungo cha ndani ingawa mstari wa DNS unaonekana kuwa sahihi.

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

systemd-resolved huhifadhi orodha moja ya resolvers kwa kila kiungo na huchagua kiungo kwa kila ombi. Kwa hiyo, ingizo sahihi kwenye wg0 hupuuzwa wakati kiungo kingine kina njia chaguo-msingi ya majina. Ongeza PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. kwenye block ya mteja ya [Interface] na uondoe mstari wa DNS =. Kisha resolvectl status wg0 inapaswa kuripoti Default Route: yes.

Ni mteja upi ninapaswa kurekebisha kwanza wakati kadhaa wamevurugika?

Rekebisha mteja mmoja wa Linux, kwa sababu ndio jukwaa pekee linalokuonyesha utaratibu huo. resolvectl status na tcpdump hukuambia ni resolver gani aliyejibu na ni interface gani iliyobeba pakiti. Programu za simu na za kompyuta hutumia thamani zilezile za DNS na AllowedIPs bila kuonyesha maelezo ya ndani. Kwa hiyo, mteja wa Linux ukishakuwa sahihi, unakili usanidi ambao tayari umethibitisha.