OpenVPN מפיץ multicast לכל לקוח, לא למנויים

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

שלוש שאלות בתוך הצהרת תכונה אחת

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

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

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

בשרת המסורתי במרחב המשתמש של OpenVPN 2.6, חבילת שידור או multicast שמגיעה מסווגת בנתיב הקלט של TUN/TAP ומועברת לשגרת פיזור השידור במקום לחיפוש לפי קבוצה. השגרה הזו עוברת על מופעי הלקוחות, מדלגת על השולח ועל כל מופע מושהה, מיישמת את בדיקת ה-VLAN במקום שבו היא מוגדרת, ומכניסה עותק לתור עבור כל לקוח שנותר. אין שלב בלולאה הזו שמתייעץ בטבלת חברות. זהו שכפול בסגנון שידור, וזה כל המנגנון.

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

תקצבו את העותקים לפני שתמדדו משהו

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

ip -s link show tun0

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

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

בדיקה עם שני לקוחות שמכריעה את שאלת ההיקף

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

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

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

לבחור בתכנון מוגבל במקום להסיר מגבלות

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

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

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