פתרון בעיות DNS ב-WireGuard: שלושה כשלים נפוצים

מדוע ה-DNS מפסיק לעבוד ברגע שמתבצע חיבור ל-WireGuard

DNS מעל WireGuard נכשל בשלוש דרכים, ולכל אחת פתרון משלה. ייתכן ששום שם לא מתפענח, ייתכן ששמות מתפענחים אך השאילתות יוצאות מהמחשב מחוץ למנהרה, או שמנהל ה-resolver של הלקוח דורס את ההגדרה שניות לאחר עליית הממשק. הבעיה כמעט לעולם אינה במנהרה עצמה. הבעיה היא בשורה אחת שמורה ללקוח לאיזה resolver לפנות, ובניתוב שקובע כיצד חבילות המידע מגיעות לאותו resolver.

WireGuard מעביר חבילות IP ואינו מכיר את ה-DNS (מערכת שמות מתחם, השירות שהופך שמות כמו example.com לכתובות IP). השורה DNS = בתוך בלוק [Interface] של הלקוח אינה הגדרה של WireGuard. היא נקראת על ידי wg-quick, מעטפת ה-shell שמעלה את הממשק, ו-wg-quick עורך את הגדרות ה-resolver של הלקוח בזמן שהמנהרה פעילה ומשחזר אותן ב-wg-quick down. לכן, כל בעיה להלן היא בעיית ניתוב או בעיית wg-quick, ולעולם לא בעיה קריפטוגרפית. אם המנהרה עצמה טרם הוקמה, התחילו ב-הקמת VPN מבוסס WireGuard על שרת VPS עצמאי וחזרו לדף זה לאחר מכן.

ודאו שהמנהרה תקינה לפני שאתם נוגעים בהגדרות ה-DNS.

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

הפקודה wg show צריכה להציג את ה-peer עם latest handshake עדכני, ושני ה-pings צריכים לקבל מענה. אם ping 1.1.1.1 נכשל ב-timeout, יש לכם בעיית forwarding או NAT (תרגום כתובות רשת) ולא בעיית DNS, ושום שינוי בהגדרות ה-resolver לא יעזור. כל דוגמה כאן משתמשת ב-10.8.0.0/24 כרשת המשנה של המנהרה וב-10.8.0.1 ככתובת המנהרה של השרת. החליפו אותן בערכים שלכם.

כשל ראשון: שום דבר לא מתבצע, כיוון שה־resolver לעולם אינו עונה

התסמין מדויק. ping 1.1.1.1 עובד, ו־curl https://example.com מחזיר את התוצאה הבאה:

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

בצעו שאילתה ל־resolver של ה־tunnel ישירות מהלקוח. dig מגיע מחבילת dnsutils ב-Ubuntu וב-Debian.

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

הפקודה הראשונה מחזירה כתובת, מה שמוכיח שחבילות מגיעות לאינטרנט דרך ה־tunnel. השנייה אינה מחזירה דבר ומדפיסה ;; communication timed out; no servers could be reached. זהו האבחון המלא: הלקוח שלכם מופנה אל 10.8.0.1, ו-10.8.0.1 אינו עונה בפורט UDP 53.

שתי סיבות גורמות לכך. או שאין resolver שרץ על השרת, או שחומת האש של השרת חוסמת את השאילתה לפני שהיא מגיעה. בדקו את שניהם בשרת.

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

resolver שרץ ומוגדר נכון יציג שורה עם 10.8.0.1:53 או 0.0.0.0:53. ב-Ubuntu ההפתעה היא בדרך כלל 127.0.0.53:53: זהו ה-stub listener של systemd-resolved, שמאזין לכתובת loopback ומכוון להיות בלתי נגיש ממכונות אחרות. הפניית לקוח VPN לשרת שה-resolver היחיד שלו הוא ה-stub הזה תייצר בדיוק את ה-timeout הזה.

הפתרון הוא resolver שמאזין לכתובת ה-tunnel, בתוספת חוק firewall אחד שמאפשר לעמיתים להגיע אליו.

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 בלבד. ב-nftables, הוסיפו את שתי השורות האלו לשרשרת 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 לאינטרנט הציבורי. סורקים ימצאו resolver רקורסיבי פתוח בתוך ימים וישתמשו בו כדי להגביר התקפות מניעת שירות (DoS), והספק שלכם יבחין בתעבורה הזו לפניכם.

הריצו שוב את dig +short @10.8.0.1 example.com מהלקוח. כתובת בפלט משמעותה שמסלול ה-resolver עובד, כך שהלקוח רק צריך להשתמש בו. הוסיפו את השורה לבלוק [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, בגלל ש־split tunnel לא מנתב את ה־resolver

זהו מצב חמור יותר, כיוון שהכל נראה תקין. שמות מתורגמים, דפים נטענים, והשאילתות עוברות בטקסט גלוי ברשת המקומית שאין בכוונתכם לתת בה אמון.

שתי תצורות גורמות לכך. הראשונה היא לקוח עם AllowedIPs = 0.0.0.0/0, ::/0 ללא שורת DNS =. ה־wg-quick מתקין את נתיב ברירת המחדל בטבלת הניתוב שלו ומוסיף חוק עם 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 באמת עונה. whoami.akamai.net הוא שם בדיקה ציבורי שעונה עם כתובת ה־IP של ה־recursive resolver שביצע את השאילתה, כך שתוכלו להשוות את תשובתו מול הכתובת הציבורית של השרת שלכם.

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

resolvectl status מדפיס בלוק אחד לכל חיבור. אם הבלוק עבור חיבור ה-ethernet או ה-wireless שלכם עדיין מציג Current DNS Server: 192.168.1.1 בזמן שהבלוק של wg0 לא מציג דבר, זוהי הדליפה. dig +short whoami.akamai.net שמחזיר את כתובת הפס הרחב הביתית שלכם במקום את כתובת השרת מאשר זאת מהצד המרוחק. השורה tcpdump היא ההוכחה שסוגרת את הדיון: פלט תקין מציב כל חבילת port 53 על wg0, ודליפה מציבה אותן על wlan0 או enp3s0.

לתיקון יש שני חלקים ושניהם נדרשים. הגדירו את DNS לכתובת שנמצאת בתוך המנהרה, וודאו שכתובת זו נמצאת בתוך 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, כך שהשאילתה מוצפנת ונשלחת לשרת. אם אתם מתעקשים על resolver ציבורי ב־split tunnel, הוסיפו אותו כ־host route: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. החבילות עוברות כעת במנהרה, אם כי הרשת המקומית עדיין יכולה לראות שבחרתם בספק הזה מסשנים קודמים. resolver שאתם מריצים בעצמכם חוסך את השאלה הזו.

הקצאת resolver היא אחד ההבדלים הנראים לעין בין WireGuard שנבנה ידנית לבין mesh מתוזמר, והיא חלק מהפשרה המתוארת ב־WireGuard בהשוואה ל־Tailscale. הפעלת שרת Headscale לשליטה עצמית מספקת את התיאום הזה בלי למסור את חומר המפתחות שלך לצד שלישי. אם דווקא המשפט האחרון מדאיג אותך, חשוב לדעת ש־Tailscale לעולם אינו מחזיק במפתחות שמצפינים את התעבורה שלך, והשאלה המדויקת יותר היא מה שרת תיאום שנפרץ או חשבון זהות שנגנב יכולים להוסיף לרשת שלך.

כשל שלישי: התנגשות בין resolvconf לבין systemd-resolved בלקוחות Linux

לקוחות macOS, Windows, iOS ו־Android מחילים את DNS = דרך האפליקציה הרשמית ואינם גורמים לבעיות מיוחדות. ב־Linux, ההגדרה מוחלת על ידי סקריפט shell שצריך לנחש איזה ממנהלי ה־resolver השונים מותקן אצלכם.

הכשל הראשון הוא רועש. sudo wg-quick up wg0 נעצר עם השגיאה:

resolvconf: command not found

wg-quick קורא ל־resolvconf, אך קובץ ה־binary הזה אינו מותקן. התקינו את המימוש שמתקשר עם 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 מחזיקה רשימת resolvers נפרדת לכל קישור (link) ובוחרת קישור לכל שאילתה. אלא אם קישור אחד מסומן כנתיב ברירת המחדל לשמות, המערכת תמשיך להשתמש ב־resolver של ממשק ה־wireless, כיוון שקישור זה נושא 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 כדומיין הניתוב לכל שם, כך ש־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 לפני שאתם מנפים שגיאות אחרות, כיוון שכלי שכותב מחדש את הקובץ הזה בכל שינוי רשת יבטל את עבודתכם ברגע הכי פחות מתאים.

השדרוג: פותר (resolver) סינון עצמי מעל המנהרה

ברגע ששאילתות עוברות באופן אמין דרך המנהרה, הפותר בצד המרוחק הופך לנקודת בקרה. הרצת AdGuard Home שם מעניקה לכל מכשיר מחובר סינון לפי רשימות חסימה ויומן שאילתות, ללא צורך בתוכנת לקוח או בהגדרה פרטנית לכל מכשיר. סקריפט ההתקנה הרשמי, שנבדק ביולי 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. יומן השאילתות יציג כעת כל חיפוש מכל עמית, מה שמהווה החלטת פרטיות ממשית ולא רק יתרון מובן מאליו: אתם מעבירים את האמון מספק האינטרנט שלכם לעצמכם, ואתם אלו שצריכים לדאוג לעדכוני האבטחה של השרת. שרת החשוף לאינטרנט דורש יישום של יסודות האבטחה תחילה, והמדריך עשר הדקות הראשונות ב-VPS חדש מכסה אותם.

FAQ

מדוע מנהרת WireGuard מתחברת אך שמות לא מתורגמים?

המנהרה מעבירה חבילות ואינה מטפלת בשמות כלל, לכן מנהרה תקינה עם תרגום שמות שבור מעידה על כך שה־resolver שאליו אתם מפנים אינו משיב. בצעו בדיקה עם dig +short @10.8.0.1 example.com מהלקוח. תגובה מסוג communication timed out משמעותה שאין resolver המאזין בכתובת המנהרה, לרוב כיוון שה־stub של systemd-resolved מאזין רק ל-127.0.0.53, או שחומת האש של השרת חוסמת תעבורת UDP בפורט 53 המגיעה ל-wg0. תקנו תחילה את המאזין, ולאחר מכן פתחו את הפורט עבור wg0 בלבד.

כיצד אוכל לבדוק אם ה-DNS שלי דולף מחוץ ל-WireGuard?

הריצו את sudo tcpdump -ni any -c 10 port 53 בלקוח ועקבו אחר עמודת ה-interface בזמן הגלישה. כל חבילה צריכה לעבור דרך wg0. אם הן מופיעות בממשק ה-wireless או ה-ethernet שלכם, השאילתות יוצאות בטקסט גלוי. dig +short whoami.akamai.net מספק חוות דעת נוספת, כיוון שהוא משיב עם הכתובת הציבורית של ה-recursive resolver שביצע את השאילתה; לכן, תשובה שאינה הכתובת של השרת שלכם מאשרת את קיום הדליפה.

האם אני זקוק לשורת DNS = אם אני משתמש ב-split tunnel?

כן, וכתובת ה-resolver חייבת להיות בתוך AllowedIPs, אחרת ללקוח אין נתיב אליה. עם AllowedIPs = 10.8.0.0/24, ה-resolver בכתובת 10.8.0.1 מכוסה והשאילתה מוצפנת. resolver ציבורי כמו 9.9.9.9 אינו מכוסה, ולכן השאילתה יוצאת דרך החיבור המקומי, גם אם שורת ה-DNS נראית תקינה.

מדוע resolvectl מציג את השרת הנכון אך השאילתות עדיין הולכות למקום אחר?

systemd-resolved מנהל רשימת resolvers לכל ממשק ובוחר ממשק לכל שאילתה, לכן רשומה תקינה ב-wg0 תתעלם אם לממשק אחר יש את נתיב ברירת המחדל לשמות. הוסיפו את 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 תקין, אתם מעתיקים תצורה שכבר הוכחה כעובדת.