SSM מעל OpenVPN: מעקב אחר מקור אחד וקבוצה אחת מתחילה עד סוף

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

קודם כל קבעו את המקור, הקבוצה והמקלט

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

טווח 232/8 שמור ל-multicast ספציפי למקור, והמודל מתואר ב-RFC 4607. אם הקבוצה שלכם מחוץ לטווח הזה בעודכם חושבים שאתם מריצים SSM, עצרו ואשרו מה הפריסה באמת מתכוונת אליו, כי הצטרפות המקלט והחלטת ההעברה של הנתב תלויות שתיהן בכך שהמודל עקבי.

בדקו שהמקלט הצטרף למקור

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

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

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

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

אמתו את מסלול החזרה לפני שאתם מסתכלים על המנהרה

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

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

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

קראו את מצב ה-multicast של הליבה ולא את התצורה

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

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

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

החליטו איך המנהרה באמת משכפלת

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

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

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