AdGuard Home עונה ללקוחות WireGuard מהכתובת LAN שלך

המנהרה פעילה, חומת האש מתירה את פורט 53, AdGuard Home פועל, ועדיין השמות לא נפתרים עבור לקוח WireGuard. השאילתה מגיעה כרגיל והתשובה יוצאת כרגיל, כך שספירות החבילות בפתרון השמות נראות בריאות והשירות נראה חף מפשע. מה שמתקלקל הוא כתובת המקור בתשובה הזו: היא יוצאת מכתובת מקומית שהלקוח מעולם לא ביקש, ומפענח ה-stub של הלקוח מחזיר אותה. רשימה אחת בקונפיגורציה של AdGuard Home מחליטה זאת, והברירת המחדל הרגילה מעבירה את ההחלטה לגרעין.

השאילתה מגיעה, התשובה יוצאת ממקום אחר

לקוח שמוגדר עם 10.6.0.1 כפתרון שלו שולח שאילתת UDP ל-10.6.0.1 פורט 53. החבילה עוברת דרך המנהרה ונוחתת על המארח, ו-AdGuard Home עונה לה. על הכבל, עם זאת, התשובה היא חבילה חדשה שלכתובת המקור שלה נבחרה על ידי מערכת המארח, ולא על פי הציפייה של הלקוח.

כאשר הפותר של הלקוח הוא סוקט מחובר, כפי שמשתמשים systemd-resolved, dnsmasq ורוב הפותרים הקצרים, הוא מקבל רק תשובות מהכתובת המדויקת שאליה נשלח. תשובה שמקורה ב-192.168.1.10 לשאילתה שנשלחה ל-10.6.0.1 נזרקת לפני שכל ניתוח מתבצע. הפותר רושם תשובה מוצלחת, הלקוח רושם פקיעת זמן, ושניהם אומרים אמת.

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

איך הקרנל בוחר את מקור התשובה

שקע UDP שמחובר ל-0.0.0.0אין לו כתובת מקור משלו, כך שכל תשובה יוצאת מפעילה חיפוש נתיב ליעד. לאחר מכן הקרנל לוקח את המקור מהנתיב: הכתובת שמוצמדה לנתיב, או הכתובת הראשית של הממשק היוצא. אין זיכרון כלשהו לגבי כתובת היעד של השאילתה.

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

ss -lunp | grep :53מראה באיזה משחק אתה נמצא. מאזין על0.0.0.0:53הוא המקרה הכללי; מאזין על10.6.0.1:53כבר קבע את התשובה. קריאת הסוקט מהירה יותר מקריאת ה-YAML, והיא משקפת מה שרץ בפועל במקום מה ששמרו לאחרונה.

מה שבפועל bind_hosts שולט בו

AdGuard Home'sdns.bind_hostsזוהי רשימת הכתובות המקומיות שהמאזין של DNS משתמש בהן. ברירת המחדל שנשלחה היא התו הכללי (*), מה שאומר לקבל על כל כתובת מקומית ולאפשר לגרעין לבחור את הכתובת המקורית לכל תשובה. החלפת התו הכללי בכתובת ששואלים ממנה הלקוחות משנה את הסוקט, ועם זאת את כתובת המקור בכל תשובה.

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

ה-YAML פשוט, והכתובת שבו היא זו שהלקוחות של המנהרה שלכם נמסרו להשתמש בה, ולא כתובת המארח הראשית:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

למה שתי התקנות של אותו פתרון לא מסכימות

המונח "מנוהל על ידי תוסף" בהקשר זה אומר שהמפענח הותקן ומפוקח על ידי חבילה אחרת: חבילת קושחה של ראוטר, חבילת NAS, או תוסף לבית חכם. חבילה זו בדרך כלל כוללת את העותק שלה של YAML של AdGuard Home ומאתחלת את התהליך בלוח הזמנים שלה, בעוד שמופע עצמאי הוא הקובץ הבינארי של הספק או מיכל שאתה מגדיר בעצמך. כך או כך, מדובר בשני תהליכים עצמאיים עם קבצי תצורה נפרדים ובחירות binding נפרדות, גם כאשר שניהם קוראים את אותה רשימת upstream ואת אותן רשימות סינון. אחד יכול לקבוע כתובת מנהרה ספציפית בעוד שהשני יורש את wildcard, וממשק האינטרנט נראה זהה משני הצדדים.

זו הסיבה לכך ש"אותו מפענח עבד לפני ההעברה" לא מוכיח דבר לגבי הקישור הנוכחי. בדוק את השקע, ואז בדוק את קובץ התצורה שהกระบיות הריצה נטענה בפועל. עותק ישן בתיקיה אחרת הוא סיבה נפוצה לכך שהעריכה נראית כאילו אין לה השפעה.

תקבע זאת, ואז בדוק מצד המנהרה

שנה אתbind_hostsלכתובת המנהרה, הפעל מחדש את השירות, ואשר שהשקע עבר:ss -lunp | grep :53צריך להראות עכשיו10.6.0.1:53ולא לא להכיל ערך כללי. אם זה עדיין מראה0.0.0.0,תהליך הריצה לא קורא את הקובץ שערכת.

ואז בדוק מהלקוח, כי הוא הצד היחיד שחשוב. שאילתא עםdig @10.6.0.1 example.comבודקת את הנתיב שהמשתמש מבצע, ותפיסה על המארח עםtcpdump -ni wg0 udp port 53מציג את כתובת המקור של התשובה ברשת. השווה זאת עם הכתובת בהגדרת הפותר של הלקוח; כאשר הן שוות, זמן ההמתנה מפסיק להיות תעלומה.

ip route get 10.6.0.2מסביר כל אי-סדירות נותרת, כי הוא מציג את הממשק והמקור שהשרת ישתמש בהם בחזרה ללקוח. אם הפלט הזה מציין את ממשק ה-LAN, שינוי ה-bind לא פותר את הכל וטבלת הניתוב היא הדבר הבא לקריאה.

מה שהגדרת ה-bind אינה יכולה לתקן

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

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