mDNS מעל WireGuard: שלושה שערים לפני שעמית עונה
Avahi זקוק לממשק כשיר, למסלול אל הקבוצה ולעמית שבעל היעד. שלושה שערים, שלוש בדיקות נפרדות ובלי פיזור.
הצבת דגל ה-multicast על התקן WireGuard הופכת את הממשק לכשיר עבור תוכנת גילוי, וזה כל מה שהדגל עושה. הוא אינו אומר לפרוטוקול לאן צריכה ללכת חבילת קבוצה, ובהתקן עם כמה עמיתים אין תשובה ברורה אחת. שלושה שערים נפרדים עומדים בין דמון פועל לבין שירות שהתגלה.
בדקו אותם לפי הסדר, כי מעבר של אחד אינו אומר דבר על הבא.
שער ראשון: הדגל והמדיניות של הדמון
התקן WireGuard בלינוקס נוצר כקישור נקודה לנקודה ללא ARP, והוא אינו נושא את דגל ה-multicast כברירת מחדל. הוספת הדגל היא שינוי ממשק מקומי, שמבצע מי שמנהל את ההתקן. ל-Avahi יש תפיסת עולם משלו מעל זה, ומדיניות ברירת המחדל שלו מדלגת לחלוטין על ממשקי נקודה לנקודה. לכן חלות שתי בדיקות כשירות בלתי תלויות לפני שחבילה אחת אפילו זזה.
אם כך הדמון זקוק להחלטה מפורשת, לא רק לתהליך פועל. הפקדים המתועדים שלו כוללים allow-interfaces, deny-interfaces ו-allow-point-to-point, והאחרון הוא ההגדרה שאנשים מפספסים.
הבדיקות שלהלן מדווחות על דגלי הקישור, על מסלול ה-multicast ועל האם תצורת הדמון מפוענחת בכלל:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkדמון שהופעל בהצלחה לא בהכרח פתח sockets בממשק שחשוב לכם. קראו את התצורה האפקטיבית שלו במקום להניח שמצב השירות שווה לכיסוי.
שער שני: המסלול אל הקבוצה
השער השני הוא ניתוב רגיל. חבילה שמוענה אל 224.0.0.251 עוקבת אחר טבלת ההעברה כמו כל דבר אחר, ואם הטבלה שולחת אותה החוצה דרך ממשק ה-LAN הפיזי, שום תצורת WireGuard לא תשנה זאת. תקנו קודם את המסלול והמשך החקירה יתקצר. ראו מה הקרנל מדווח עבור כתובת הקבוצה לפני שנוגעים במפתחות עמית כלשהם.
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
בלי מסלול ספציפי, הקרנל נופל חזרה לטיפול ה-multicast של הקישור עצמו, וזו הסיבה שברירת המחדל נראית נכונה ב-LAN שטוח ושגויה ברגע שאותה תעבורת קבוצה אמורה לצאת דרך מנהרה. הכשל שקט מצד השולח: השאילתה הולכת לאנשהו, והתשובה לעולם לא מגיעה.
שער שלישי: WireGuard בוחר עמית אחד לכל חבילה
WireGuard בוחר עמית יוצא על ידי חיפוש היעד בקבוצות הכתובות המותרות, ונתיב השידור של לינוקס מבצע את החיפוש הזה פעם אחת לכל חבילה. יש תוצאה אחת, והחבילה מוצפנת עבור אותו עמית. אותה קידומת קבוצה שמופיעה ברשימות המותרות של כמה עמיתים אינה יוצרת חברות או שכפול; היא יוצרת חיפוש דו-משמעי שמסתיים באחד מהם.
בקישור ייעודי עם שני קצוות זה בדיוק מה שאתם רוצים, כי יש נמען אחד מיועד לתעבורת הקבוצה שנשאת בכוונה. בממשק עם חמישה עמיתים זו מגבלה, לא תכונה, והתיקון שייך לתכנון ולא לתצורה של עמית בודד כלשהו.
תכנון מפוזר זקוק לממסר מפורש, לקישורים נפרדים או למנגנון גילוי שונה לחלוטין. פרסום מתכון לשני קצוות כפתרון ללקוחות רבים משום שכל לקוח יכול לבצע ping לשער הוא הדרך שבה זה נפרס שלא כהלכה.
הכיוון הנכנס נבדק אחרת: המקור של חבילה שהתקבלה חייב ליפול בתוך הרשימה המורשית של העמית המאומת. הוספת יעד multicast שם אינה מחליפה את הבעלות האמיתית על המקור של השולח.
השתקפות היא גבול, לא גשר
המשקף של Avahi משחזר הודעות mDNS בין הממשקים שהוא בוחר, בשכבת היישום. זהו גבול גילוי בין רשתות, לא גשר Ethernet ולא נתב multicast כללי. שני משקפים המחוברים לאותן רשתות ייצרו בשמחה לופ של הכרזות חוזרות.
ההשתקפות גם מוסרת שמות שירות והמטא-נתונים שלהם לרשת אחרת, וזו החלטת פרטיות לא פחות מהחלטת ניתוב. הגבילו את הממשקים הנבחרים, והשתמשו במסנני שירות היכן שהגרסה המותקנת תומכת בהם, כך שרק ההכרזות שמשתמש מורשה זקוק להן יחצו את הגבול.
גילוי ושימוש נשארים תוצאות נפרדות. לקוח יכול לראות הכרזה על שירות שכתובתו המוכרזת אינה ניתנת להשגה מהמקום שבו הלקוח נמצא, או שהמדיניות שלו דוחה את הפורט שלה. אשרו את חיבור השירות לאחר שההכרזה מופיעה, ואם היישום תומך בשם DNS יציב או בכתובת שרת מפורשת, העדיפו זאת על פני הרחבת הגילוי המקומי של הקישור. תיאור הניתוב במפתח הצפנה מכסה את בחירת העמית על בסיס היעד שכל זה תלוי בו.