แก้ DNS ผ่าน WireGuard: 3 ปัญหาที่พบบ่อย

เหตุใด DNS จึงใช้งานไม่ได้ทันทีที่อุโมงค์ WireGuard เชื่อมต่อ

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

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

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

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

อาการที่เกิดขึ้นมีความชัดเจน 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 leaks เนื่องจาก split tunnel ไม่ได้กำหนดเส้นทางให้ resolver

ปัญหานี้ร้ายแรงกว่า เพราะทุกอย่างดูเหมือนจะทำงานได้ปกติ ชื่อโดเมนถูกแปลงเป็น IP ได้ หน้าเว็บโหลดได้ แต่การสืบค้นข้อมูลกลับวิ่งผ่านเครือข่ายท้องถิ่นที่คุณไม่ต้องการไว้วางใจในรูปแบบข้อความธรรมดา (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 ที่เป็นผู้ถาม คุณจึงสามารถเปรียบเทียบคำตอบนั้นกับ public 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 ส่งคืน address ของบรอดแบนด์ที่บ้านแทนที่จะเป็น address ของเซิร์ฟเวอร์ เป็นการยืนยันจากฝั่งปลายทาง บรรทัด tcpdump คือหลักฐานที่ยุติข้อโต้แย้งทั้งหมด: ผลลัพธ์ที่ถูกต้องคือแพ็กเก็ตพอร์ต 53 ทุกตัวที่ออกจากเครื่องจะต้องผ่าน wg0 และหากเกิด leak แพ็กเก็ตเหล่านั้นจะไปปรากฏบน wlan0 หรือ enp3s0 แพ็กเก็ตบน lo ที่รับส่งกับ 127.0.0.53 คือแอปพลิเคชันที่คุยกับ systemd-resolved stub ในเครื่อง ซึ่งไม่ใช่การรั่วไหลของข้อมูล

การแก้ไขมีสองส่วนและจำเป็นต้องทำทั้งคู่ ตั้งค่า 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 ที่โฮสต์เอง ช่วยให้คุณได้รับการประสานงานนั้นโดยไม่ต้องมอบกุญแจเข้ารหัสให้กับบุคคลที่สาม หากวลีสุดท้ายนั้นเป็นสิ่งที่คุณกังวล โปรดทราบว่า Tailscale ไม่เคยเก็บกุญแจที่ใช้เข้ารหัสทราฟฟิกของคุณ และคำถามที่สำคัญกว่าคือ coordination server ที่ถูกบุกรุกหรือบัญชีที่ถูกขโมยจะสามารถสร้างผลกระทบอะไรต่อเครือข่ายของคุณได้บ้าง

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

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

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

resolvconf: command not found

wg-quick เรียกใช้ resolvconf แต่ไม่มี binary ดังกล่าวติดตั้งอยู่ บน Debian 12 และ Ubuntu 24.04 ขึ้นไป คำสั่ง resolvconf ที่ใช้ติดต่อ systemd-resolved อยู่ในแพ็กเกจ systemd-resolved ดังนั้นให้ติดตั้งแพ็กเกจนี้ แล้วนำ interface ขึ้นมาใหม่ Ubuntu 22.04 ไม่มีแพ็กเกจแยกสำหรับคำสั่งนี้ ให้สร้าง compatibility link เองด้วย sudo ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf แล้วข้ามบรรทัดติดตั้งแพ็กเกจ

sudo apt install -y systemd-resolved
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 ได้ถูกต้อง แต่ lookup ยังคงไปถึง resolver เดิม systemd-resolved ไม่ได้ละเลย wg0 ชื่อที่ไม่ตรงกับ routing domain ใดเลยจะถูกส่งไปยัง DNS server ของทุก link ที่ถูกนับว่าเป็น default route และ link ที่มี DNS server แต่ไม่มี route-only domain จะถูกนับเป็นหนึ่งรายการโดยค่าเริ่มต้น ดังนั้น query จึงถูกส่งไปยัง 10.8.0.1 และเราเตอร์บน wireless link พร้อมกัน แล้วใช้คำตอบแรกที่สำเร็จ เราเตอร์อยู่ห่างออกไปหนึ่ง hop และมักตอบกลับก่อน และไม่ว่ากรณีใด query ก็ได้ออกไปในรูปแบบ cleartext แล้ว ชื่อภายใต้ search domain ของ wireless link เอง เช่น lan จะถูกส่งไปยัง link นั้นเท่านั้น เพราะ routing domain ที่จำเพาะที่สุดจะมีผลเหนือกว่า

เมื่อ wg-quick ตั้งค่า DNS = ผ่าน wrapper resolvconf ของ systemd เอง ระบบจะขอ catch-all routing domain ให้อยู่แล้ว ดังนั้นความล้มเหลวนี้มักเกิดขึ้นเมื่อมี resolvconf implementation อื่นหรือ network manager เป็นผู้ตั้งค่า การกำหนดค่าอย่างชัดเจนจะตัดการคาดเดาออก

ตั้งค่า resolver และกำหนด catch-all routing domain ในขั้นตอนเดียวกัน %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

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

resolvectl status wg0

ผลลัพธ์ที่ทำงานถูกต้องจะมี DNS Servers: 10.8.0.1 และ DNS Domain: ~. หากไม่มี ~. แสดงว่าส่วน resolvectl domain ยังไม่ได้ทำงาน และ wg0 กลับมาแข่งกับ link อื่นอีกครั้ง อย่าใช้ default route flag เป็นตัวตรวจสอบ เพราะ flag ดังกล่าวจะแสดง yes หรือ +DefaultRoute บนบรรทัด Protocols โดยขึ้นอยู่กับ systemd version แม้ไม่มี ~. เนื่องจาก link ที่ไม่มี route-only domain จะถือเป็น default route อยู่แล้ว

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

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

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

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

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

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

FAQ

ทำไม WireGuard tunnel เชื่อมต่อได้แต่แก้ไขชื่อ (name resolution) ไม่ได้?

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

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

รัน sudo tcpdump -ni any -c 10 port 53 บนไคลเอนต์และสังเกตคอลัมน์ interface ในขณะที่คุณใช้งาน แพ็กเก็ตทุกตัวที่ออกจากเครื่องควรอยู่บน wg0 ส่วนแพ็กเก็ตบน lo ที่รับส่งกับ 127.0.0.53 คือ systemd-resolved stub ของระบบซึ่งถือว่าปกติ หากแพ็กเก็ตปรากฏบน interface ของ wireless หรือ ethernet แสดงว่าการสอบถามข้อมูลนั้นถูกส่งออกไปแบบไม่เข้ารหัส dig +short whoami.akamai.net เป็นอีกวิธีในการตรวจสอบ เพราะมันจะตอบกลับด้วย public address ของ 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 จะไม่ถูกครอบคลุม ทำให้คำถามถูกส่งออกผ่านเครือข่ายท้องถิ่นแม้ว่าบรรทัด DNS จะดูถูกต้องก็ตาม

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

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

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

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