วิธีแก้ปัญหา DNS ใช้งานไม่ได้เมื่อเชื่อมต่อ WireGuard VPN

เหตุใด DNS จึงใช้งานไม่ได้ทันทีที่ WireGuard tunnel เริ่มทำงาน

DNS ผ่าน WireGuard มักล้มเหลวด้วย 3 สาเหตุหลัก ซึ่งแต่ละสาเหตุมีวิธีแก้ไขเฉพาะตัว ปัญหาอาจเกิดจากการที่ไม่มีการตอบกลับของชื่อโดเมนเลย, การที่ query ออกไปนอก tunnel หรือการที่ตัวจัดการ resolver ของเครื่องไคลเอนต์เขียนทับการตั้งค่าเดิมหลังจาก interface เริ่มทำงานไม่กี่วินาที ปัญหาแทบไม่เคยเกิดจากตัว tunnel เอง แต่เกิดจากบรรทัดคำสั่งที่ระบุว่าไคลเอนต์ต้องถาม resolver ตัวใด และการกำหนดเส้นทาง (routing) ที่ตัดสินว่าแพ็กเก็ตไปยัง resolver นั้นจะเดินทางอย่างไร

WireGuard ทำหน้าที่ส่งผ่าน IP packet และไม่มีความรู้เรื่อง DNS (Domain Name System ซึ่งเป็นบริการที่แปลงชื่ออย่าง example.com ให้เป็น IP address) บรรทัด DNS = ในบล็อก [Interface] ของไคลเอนต์ไม่ใช่การตั้งค่าของ WireGuard โดยตรง แต่ถูกอ่านโดย wg-quick ซึ่งเป็น shell wrapper ที่ใช้เปิด interface และ wg-quick จะทำการแก้ไขการตั้งค่า resolver ของไคลเอนต์ในขณะที่ tunnel ทำงานอยู่ และกู้คืนค่าเดิมเมื่อ wg-quick down ดังนั้นปัญหาทุกอย่างด้านล่างนี้จึงเป็นปัญหาเรื่อง routing หรือ wg-quick ไม่ใช่ปัญหาเรื่องการเข้ารหัสลับ หาก tunnel ยังไม่ถูกสร้างขึ้น ให้เริ่มจาก การทำ self-hosted WireGuard VPN บน VPS ของคุณเอง แล้วค่อยกลับมาที่หน้านี้

ตรวจสอบให้แน่ใจว่า tunnel ทำงานได้ปกติก่อนที่จะเริ่มแก้ไขการตั้งค่า 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) แสดงว่าคุณมีปัญหาเรื่องการส่งต่อแพ็กเก็ตหรือ NAT (Network Address Translation) ไม่ใช่ปัญหา DNS และการปรับแต่ง resolver config จะไม่ช่วยอะไร หาก ping ตอบกลับได้แต่ throughput ตกทันทีที่มีการรับส่งข้อมูลจริง นั่นเป็นปัญหาแยกต่างหาก และ ปัญหา WireGuard ทำงานช้าเกือบทั้งหมดมีสาเหตุมาจาก MTU ไม่ใช่สิ่งที่ระบุในหน้านี้ ตัวอย่างทั้งหมดในที่นี้ใช้ 10.8.0.0/24 เป็น tunnel subnet และ 10.8.0.1 เป็น tunnel address ของเซิร์ฟเวอร์ โปรดแทนที่ด้วยค่าของคุณเอง

ความล้มเหลวประการที่หนึ่ง: ไม่มีการตอบกลับใดๆ เนื่องจากตัวแก้ไขชื่อโดเมนไม่ตอบสนอง

อาการที่เกิดขึ้นมีความชัดเจน ping 1.1.1.1 ทำงานได้ปกติ และ curl https://example.com ส่งผลลัพธ์ดังนี้:

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

ให้สอบถามไปยังตัวแก้ไขชื่อโดเมนของอุโมงค์โดยตรงจากฝั่งไคลเอนต์ dig เป็นเครื่องมือที่อยู่ในแพ็กเกจ dnsutils บน Ubuntu และ Debian

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

คำสั่งแรกส่งคืนที่อยู่ IP ซึ่งพิสูจน์ว่าแพ็กเก็ตสามารถออกสู่อินเทอร์เน็ตผ่านอุโมงค์ได้ ส่วนคำสั่งที่สองไม่ส่งคืนค่าใดๆ และแสดงข้อความ ;; communication timed out; no servers could be reached นี่คือการวินิจฉัยทั้งหมด: ไคลเอนต์ของคุณถูกชี้ไปยัง 10.8.0.1 และ 10.8.0.1 ไม่ตอบสนองที่พอร์ต UDP 53

สาเหตุที่ทำให้เกิดปัญหานี้มีสองประการ คือไม่มีตัวแก้ไขชื่อโดเมนทำงานอยู่บนเซิร์ฟเวอร์ หรือไฟร์วอลล์ของเซิร์ฟเวอร์ดรอปแพ็กเก็ตก่อนที่จะมาถึง ให้ตรวจสอบทั้งสองกรณีบนเซิร์ฟเวอร์

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

ตัวแก้ไขชื่อโดเมนที่ทำงานอยู่และผูกพอร์ตอย่างถูกต้องจะแสดงบรรทัดที่มี 10.8.0.1:53 หรือ 0.0.0.0:53 สำหรับบน Ubuntu สิ่งที่มักพบคือ 127.0.0.53:53 ซึ่งเป็น stub listener ของ systemd-resolved ที่ผูกอยู่กับ loopback address และถูกตั้งค่ามาให้ไม่สามารถเข้าถึงได้จากเครื่องอื่น การชี้ VPN ไคลเอนต์ไปยังเซิร์ฟเวอร์ที่มีเพียง stub นี้จะทำให้เกิดอาการ timeout ดังกล่าว

วิธีแก้ไขคือการใช้ตัวแก้ไขชื่อโดเมนที่ฟังคำขอผ่านที่อยู่ IP ของอุโมงค์ พร้อมกับกฎไฟร์วอลล์หนึ่งข้อที่อนุญาตให้ peer เข้าถึงได้

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 ให้เพิ่มสองบรรทัดนี้ลงใน chain input ในไฟล์ /etc/nftables.conf แล้วโหลดการตั้งค่าใหม่ด้วย sudo systemctl reload nftables

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

หากใช้ ufw คำสั่ง sudo ufw allow in on wg0 to any port 53 จะทำหน้าที่เดียวกัน ห้ามเปิดพอร์ต 53 สู่สาธารณะโดยเด็ดขาด ตัวแก้ไขชื่อโดเมนแบบ recursive ที่เปิดทิ้งไว้จะถูกสแกนพบภายในไม่กี่วันและถูกนำไปใช้ขยายผลการโจมตีแบบ denial of service ซึ่งผู้ให้บริการของคุณจะตรวจพบทราฟฟิกดังกล่าวได้ก่อนที่คุณจะรู้ตัว

ให้รัน dig +short @10.8.0.1 example.com จากฝั่งไคลเอนต์อีกครั้ง หากผลลัพธ์แสดงที่อยู่ IP แสดงว่าเส้นทางของตัวแก้ไขชื่อโดเมนทำงานได้แล้ว ตอนนี้ไคลเอนต์เพียงแค่ต้องใช้งานมัน ให้เพิ่มบรรทัดดังกล่าวลงในบล็อก [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 leak เนื่องจาก split tunnel ไม่ได้กำหนดเส้นทางให้ resolver

กรณีนี้ร้ายแรงกว่า เพราะทุกอย่างดูเหมือนทำงานได้ตามปกติ ชื่อโดเมนถูกแปลงเป็น IP ได้ หน้าเว็บโหลดได้ แต่คำร้องขอ (query) กลับวิ่งผ่านเครือข่ายท้องถิ่นที่คุณไม่ต้องการให้ความไว้วางใจในรูปแบบข้อความธรรมดา (cleartext)

การตั้งค่าสองแบบที่เป็นสาเหตุของปัญหานี้ แบบแรกคือไคลเอนต์ที่ใช้ AllowedIPs = 0.0.0.0/0, ::/0 โดยไม่มีบรรทัด DNS = ตัว wg-quick จะติดตั้ง default route ลงในตารางเส้นทางของตัวเองและเพิ่มกฎด้วย suppress_prefixlength 0 ซึ่งจงใจคงเส้นทางท้องถิ่นที่เฉพาะเจาะจงไว้เพื่อให้เครื่องยังคงเข้าถึงเครื่องพิมพ์ได้ Resolver ที่ไคลเอนต์ได้รับผ่าน DHCP ซึ่งมักจะเป็นเราเตอร์ที่ 192.168.1.1 จะตรงกับเส้นทางท้องถิ่นเหล่านั้น ทราฟฟิกของคุณจะวิ่งผ่านอุโมงค์ แต่เครือข่ายท้องถิ่นจะยังคงได้รับรายการชื่อทั้งหมดที่คุณค้นหา

แบบที่สองคือ split tunnel: AllowedIPs = 10.8.0.0/24 ร่วมกับ DNS = 9.9.9.9 เนื่องจาก 9.9.9.9 ไม่ได้อยู่ภายใน AllowedIPs ไคลเอนต์จึงไม่มีเส้นทางไปหา resolver ผ่านอุโมงค์ คำร้องขอจึงหลุดออกไปทางลิงก์ท้องถิ่นเหมือนกับกรณีแรก

พิสูจน์ว่า resolver ใดกันแน่ที่เป็นผู้ตอบกลับ whoami.akamai.net เป็นชื่อทดสอบสาธารณะที่จะตอบกลับด้วย IP address ของ recursive resolver ที่เป็นผู้สอบถาม คุณจึงสามารถนำคำตอบนั้นมาเปรียบเทียบกับ IP address สาธารณะของเซิร์ฟเวอร์คุณได้

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

resolvectl status จะแสดงผลลัพธ์หนึ่งบล็อกต่อหนึ่งลิงก์ หากบล็อกสำหรับอีเทอร์เน็ตหรือลิงก์ไร้สายของคุณยังคงแสดง Current DNS Server: 192.168.1.1 ในขณะที่บล็อก wg0 ไม่แสดงข้อมูล นั่นคือการรั่วไหล (leak) การที่ dig +short whoami.akamai.net ส่งคืน IP address ของบรอดแบนด์ที่บ้านแทนที่จะเป็น IP address ของเซิร์ฟเวอร์ เป็นการยืนยันจากฝั่งปลายทาง บรรทัด tcpdump คือหลักฐานที่ยุติข้อโต้แย้งทั้งหมด: ผลลัพธ์ที่ถูกต้องจะต้องส่งแพ็กเก็ตพอร์ต 53 ทั้งหมดผ่าน wg0 และหากมีการรั่วไหล แพ็กเก็ตเหล่านั้นจะไปปรากฏบน wlan0 หรือ enp3s0

การแก้ไขมีสองส่วนและจำเป็นต้องทำทั้งคู่ กำหนด DNS ให้เป็น 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 ทำให้คำร้องขอถูกเข้ารหัสและส่งไปยังเซิร์ฟเวอร์ หากคุณยืนยันที่จะใช้ public resolver บน split tunnel ให้เพิ่มเป็น host route ดังนี้: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32 แพ็กเก็ตจะถูกส่งผ่านอุโมงค์ แม้ว่าเครือข่ายท้องถิ่นจะยังคงเห็นว่าคุณเลือกผู้ให้บริการรายนั้นจากเซสชันก่อนหน้าก็ตาม การใช้ resolver ที่คุณดูแลเองจะช่วยตัดปัญหานี้ออกไป

การกำหนด Resolver เป็นความแตกต่างที่เห็นได้ชัดระหว่าง WireGuard ที่ตั้งค่าด้วยตนเองกับ mesh ที่มีระบบประสานงาน ซึ่งเป็นส่วนหนึ่งของข้อแลกเปลี่ยนใน WireGuard เปรียบเทียบกับ Tailscale การใช้งาน Headscale control server ที่โฮสต์ด้วยตนเอง ช่วยให้มีการประสานงานดังกล่าว โดยไม่ต้องมอบ key material ให้บุคคลที่สาม หากประโยคส่วนท้ายนั้นเป็นสิ่งที่ทำให้คุณกังวล โปรดทราบว่า Tailscale ไม่เคยถือ keys ที่ใช้เข้ารหัส traffic ของคุณ และคำถามที่ตรงประเด็นกว่าคือ coordination server ที่ถูกเจาะระบบหรือ identity account ที่ถูกขโมย จะเพิ่มสิ่งใดเข้ามาในเครือข่ายของคุณได้บ้าง

ความล้มเหลวที่สาม: resolvconf และ systemd-resolved ขัดแย้งกันบนไคลเอนต์ Linux

ไคลเอนต์ macOS, Windows, iOS และ Android จะนำ DNS = ไปใช้งานผ่านแอปอย่างเป็นทางการและมักไม่ค่อยพบปัญหา แต่สำหรับ Linux การตั้งค่าจะถูกนำไปใช้ผ่านเชลล์สคริปต์ที่ต้องคาดเดาว่าคุณกำลังใช้ตัวจัดการ DNS resolver ตัวใดจากที่มีอยู่หลายตัว

ความล้มเหลวแรกนั้นชัดเจน sudo wg-quick up wg0 จะหยุดทำงานพร้อมข้อความ:

resolvconf: command not found

wg-quick เรียกใช้งาน resolvconf แต่ไบนารีดังกล่าวไม่ได้ถูกติดตั้งไว้ ให้ติดตั้งตัวจัดการที่รองรับการทำงานร่วมกับ systemd-resolved จากนั้นจึงเปิดใช้งานอินเทอร์เฟซอีกครั้ง

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

ความล้มเหลวที่สองนั้นเงียบเชียบและเป็นปัญหาที่ทำให้เสียเวลาไปทั้งคืน อินเทอร์เฟซเปิดใช้งานได้ปกติ resolvectl status wg0 แสดงผล DNS Servers: 10.8.0.1 อย่างถูกต้อง แต่การค้นหาชื่อโดเมนยังคงส่งไปยัง resolver ตัวเดิม systemd-resolved จะเก็บรายการ resolver แยกตามลิงก์และเลือกใช้ลิงก์ต่อการค้นหาหนึ่งครั้ง หากไม่มีลิงก์ใดถูกกำหนดเป็นเส้นทางหลัก (default route) สำหรับชื่อโดเมน ระบบจะยังคงใช้ resolver ของการเชื่อมต่อไร้สายต่อไป เนื่องจากลิงก์นั้นมี search domain กำหนดไว้ในขณะที่ของคุณไม่มี

ให้ตั้งค่า resolver และกำหนดเส้นทางหลักไปพร้อมกันในขั้นตอนเดียว %i จะขยายผลเป็นชื่ออินเทอร์เฟซ ดังนั้นบล็อกคำสั่งนี้จึงสามารถใช้งานได้โดยไม่ต้องแก้ไขบนอินเทอร์เฟซใดๆ

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

ให้ลบบรรทัด DNS = ออกเมื่อคุณใช้ PostUp ในลักษณะนี้ เพราะมิฉะนั้นจะมีกลไกสองตัวที่คอยเขียนสถานะของ resolver และมีเพียงตัวเดียวเท่านั้นที่จะล้างค่าทิ้งหลังจากเสร็จสิ้น อาร์กิวเมนต์ ~. คือส่วนที่สำคัญที่สุด เพราะมันทำเครื่องหมายให้ wg0 เป็น routing domain สำหรับทุกชื่อโดเมน ส่งผลให้ systemd-resolved ส่งคำค้นหาทั้งหมดไปที่นั่นแทนที่จะเลือกใช้ลิงก์ต่อการค้นหา ให้ตรวจสอบผลลัพธ์ดังนี้

resolvectl status wg0

ผลลัพธ์ที่ถูกต้องควรมี DNS Servers: 10.8.0.1 และ Default Route: yes ปรากฏอยู่ หาก Default Route แสดงค่าเป็น no แสดงว่าส่วนของ resolvectl domain ไม่ได้ทำงาน และคุณจะกลับไปสู่ปัญหาการเลือกใช้ลิงก์ตามเดิม

ยังมีอีกกรณีที่ควรทราบ หาก /etc/resolv.conf เป็นไฟล์จริงแทนที่จะเป็น symlink ไปยัง /run/systemd/resolve/stub-resolv.conf แสดงว่ามีโปรแกรมอื่นควบคุมไฟล์นี้อยู่ ซึ่งมักจะเป็น NetworkManager หรือ container runtime ให้รันคำสั่ง ls -l /etc/resolv.conf ก่อนที่จะเริ่มแก้ไขปัญหาอื่นใด เพราะเครื่องมือที่คอยเขียนไฟล์นั้นทับทุกครั้งที่มีการเปลี่ยนแปลงเครือข่ายจะทำให้สิ่งที่คุณตั้งค่าไว้สูญเปล่าในเวลาที่ไม่เหมาะสมที่สุด

การอัปเกรด: การใช้ตัวกรอง DNS ของคุณเองผ่านอุโมงค์เครือข่าย

เมื่อการสืบค้นข้อมูลสามารถส่งผ่านอุโมงค์เครือข่ายได้อย่างน่าเชื่อถือ ตัวแก้ไข DNS (resolver) ที่ปลายทางจะกลายเป็นจุดควบคุมหลัก การรัน AdGuard Home ไว้ที่นั่นจะช่วยให้ทุกอุปกรณ์ที่เชื่อมต่อได้รับประโยชน์จากการกรองด้วย blocklist และบันทึกการสืบค้น โดยไม่จำเป็นต้องติดตั้งซอฟต์แวร์บนไคลเอนต์หรือตั้งค่าแยกรายอุปกรณ์ สคริปต์ติดตั้งอย่างเป็นทางการซึ่งตรวจสอบเมื่อเดือนกรกฎาคม 2026 มีเพียงบรรทัดเดียว

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

วิซาร์ดการตั้งค่าจะรอรับการเชื่อมต่อที่พอร์ต 3000 ในการรันครั้งแรก ให้เข้าถึงผ่านอุโมงค์เครือข่ายที่ http://10.8.0.1:3000 แทนการเปิดพอร์ตดังกล่าวสู่สาธารณะ และในวิซาร์ดให้ตั้งค่าทั้งที่อยู่สำหรับรับฟัง DNS และที่อยู่สำหรับรับฟังหน้าผู้ดูแลระบบเป็น 10.8.0.1 หาก unbound จากความล้มเหลวครั้งแรกยังคงใช้ที่อยู่เดิมอยู่ ให้หยุดการทำงานก่อนด้วย sudo systemctl disable --now unbound เนื่องจากสองกระบวนการไม่สามารถผูก (bind) พอร์ต UDP 53 บนที่อยู่เดียวกันได้ และกระบวนการที่สองจะยุติการทำงานด้วย listen udp 10.8.0.1:53: bind: address already in use

การตั้งค่าของไคลเอนต์ไม่จำเป็นต้องเปลี่ยนแปลงหากระบุไว้ที่ DNS = 10.8.0.1 อยู่แล้ว บันทึกการสืบค้นจะแสดงทุกการค้นหาจากทุก peer ซึ่งเป็นการตัดสินใจด้านความเป็นส่วนตัวที่แท้จริงมากกว่าการได้มาเปล่าๆ คุณกำลังย้ายความไว้วางใจจากผู้ให้บริการอินเทอร์เน็ตมาไว้ที่ตัวคุณเอง และคุณคือผู้ที่ต้องคอยดูแลให้เซิร์ฟเวอร์นั้นได้รับการแพตช์อยู่เสมอ เซิร์ฟเวอร์ที่เปิดเผยต่ออินเทอร์เน็ตจำเป็นต้องมีการตั้งค่าพื้นฐานให้เรียบร้อยก่อน ซึ่ง สิบนาทีแรกบน VPS ใหม่ ได้ครอบคลุมเนื้อหาเหล่านั้นไว้แล้ว

FAQ

ทำไม WireGuard tunnel ของฉันเชื่อมต่อได้ แต่ไม่สามารถ resolve ชื่อโดเมนได้?

อุโมงค์ (tunnel) ทำหน้าที่เพียงส่งผ่านแพ็กเก็ตและไม่ได้จัดการเรื่องชื่อโดเมน ดังนั้นหากอุโมงค์ทำงานปกติแต่การค้นหาชื่อล้มเหลว แสดงว่าตัว resolver ที่คุณระบุไว้ไม่ตอบสนอง ให้ทดสอบด้วย dig +short @10.8.0.1 example.com จากฝั่งไคลเอนต์ หากได้รับคำตอบเป็น communication timed out แสดงว่าไม่มี resolver ฟังอยู่ที่แอดเดรสของอุโมงค์นั้น ซึ่งมักเกิดจาก systemd-resolved stub ผูกไว้ที่ 127.0.0.53 เท่านั้น หรือไฟร์วอลล์ของเซิร์ฟเวอร์กำลังดรอป UDP พอร์ต 53 ที่เข้ามาทาง wg0 ให้แก้ไขที่ตัว listener ก่อน แล้วจึงเปิดพอร์ตสำหรับ wg0 เท่านั้น

ฉันจะตรวจสอบได้อย่างไรว่า DNS ของฉันรั่วไหลผ่าน WireGuard?

รัน sudo tcpdump -ni any -c 10 port 53 บนไคลเอนต์และสังเกตคอลัมน์ interface ในขณะที่คุณใช้งาน แพ็กเก็ตทุกรายการควรปรากฏบน wg0 หากพบว่าแพ็กเก็ตปรากฏบนอินเทอร์เฟซ wireless หรือ ethernet แสดงว่าการสอบถาม (query) กำลังถูกส่งออกไปแบบไม่เข้ารหัส dig +short whoami.akamai.net สามารถใช้ตรวจสอบยืนยันได้อีกทางหนึ่ง เนื่องจากจะตอบกลับด้วยแอดเดรสสาธารณะของ recursive resolver ที่เป็นผู้สอบถาม ดังนั้นหากคำตอบที่ได้ไม่ใช่แอดเดรสของเซิร์ฟเวอร์คุณ ก็เป็นการยืนยันว่าเกิดการรั่วไหล

ฉันจำเป็นต้องมีบรรทัด DNS = หรือไม่หากใช้ split tunnel?

จำเป็น และแอดเดรสของ resolver ต้องอยู่ภายใน AllowedIPs ด้วย มิฉะนั้นไคลเอนต์จะไม่มีเส้นทาง (route) ไปยัง resolver นั้น หากใช้ AllowedIPs = 10.8.0.0/24 ตัว resolver ที่ 10.8.0.1 จะถูกครอบคลุมและคำสอบถามจะถูกเข้ารหัส แต่หากใช้ public resolver เช่น 9.9.9.9 จะไม่ถูกครอบคลุม ทำให้คำสอบถามหลุดออกไปทาง local link แม้ว่าบรรทัด DNS จะดูถูกต้องก็ตาม

ทำไม resolvectl ถึงแสดงเซิร์ฟเวอร์ที่ถูกต้อง แต่การค้นหายังไปที่อื่น?

systemd-resolved เก็บรายการ resolver แยกตาม link และเลือก link สำหรับแต่ละการสอบถาม ดังนั้นรายการที่ถูกต้องบน wg0 อาจถูกละเลยหากมี link อื่นที่ถือ default route สำหรับชื่อโดเมนอยู่ ให้เพิ่ม PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. เข้าไปในบล็อก [Interface] ของไคลเอนต์ และลบบรรทัด DNS = ออก จากนั้น resolvectl status wg0 ควรจะรายงานเป็น Default Route: yes

ฉันควรแก้ไขไคลเอนต์ตัวไหนก่อนเมื่อมีหลายตัวที่ใช้งานไม่ได้?

ให้แก้ไขไคลเอนต์ Linux ก่อน เพราะเป็นแพลตฟอร์มเดียวที่แสดงกลไกการทำงานให้คุณเห็น resolvectl status และ tcpdump จะบอกคุณว่า resolver ใดเป็นผู้ตอบและอินเทอร์เฟซใดเป็นผู้ส่งแพ็กเก็ต แอปบนโทรศัพท์และเดสก์ท็อปจะใช้ค่า DNS และ AllowedIPs เดียวกันโดยไม่มีการแสดงรายละเอียดการเชื่อมต่อ ดังนั้นเมื่อไคลเอนต์ Linux ทำงานได้ถูกต้องแล้ว คุณก็เพียงแค่คัดลอกการตั้งค่าที่คุณพิสูจน์แล้วว่าใช้งานได้ไปใช้ต่อเท่านั้น