סימון פורט ה-VPN אינו נותן עדיפות לשיחות קוליות
סימון פורט ה-VPN כעדיפות מקדם את השיחה ואת הגיבוי באותו מנהרה. הקול זקוק לסיווג לפני ההצפנה ולתור שאתם שולטים בו.
סימון פורט ה-UDP של ה-VPN כעדיפות גבוהה הוא שינוי ה-QoS הנפוץ ביותר לקול, והוא אינו מפריד בין שיחה לבין העברת הקבצים שחולקת את אותה מנהרה. שני הזרמים יוצאים דרך אותו שקע מוצפן. הסימון אומר לצעד הבא שהכול חשוב באותה מידה, וזה כמו לא לומר לו דבר. מה שמגן על שיחה הוא סיווג מהימן לפני ההצפנה בתוספת תור שאתם באמת שולטים בו.
המנהרה מסתירה את הזרם שרציתם לסווג
ההצפנה מחליפה את הכותרות הפנימיות בכותרת חיצונית אחת לכל מנהרה. לאחר מכן, קול ותעבורת גיבוי מציגים את אותו מקור, יעד ופורט תעבורה, ולכן מסווג שמבוסס על פורט המנהרה אינו יכול להבדיל ביניהם. כל מה שתקדמו, תקדמו אותו כגוש אחד.
ערך DSCP שנקבע על ידי היישום המקורי שורד רק אם משהו מעתיק אותו החוצה. ב-OpenVPN 2.6 יש passtos, שמתועד עם תחום IPv4; IPsec מיישם מדיניות העתקה או מיפוי משלו בגבול המנהרה. בלי הצעד הזה המנות החיצונית מסומנת בכל ברירת מחדל שהממשק של המנהרה משתמש בה, והתור בהמשך לעולם לא לומד ששיחה נמצאת בפנים.
סימונים מועתקים ראויים לאותה חשדנות כמו כל ערך שמספק הלקוח. תחנת עבודה יכולה לדרוש העברה מזורזת עבור משימת גיבוי, ולכן קבלה וסימון מחדש בגבול האמון צריכים להיות בתכנון לפני שמאמינים לסימון.
עדיפות נספרת רק במקום שבו התור נוצר
קישור עולה רווי הוא מה שהופך קודק טוב לקול רובוטי, והתור שמתמלא נמצא בדרך כלל בהתקן הגישה או במאגר של הספק. עיצוב הנתיב היוצא לקצב השמיש, פחות תקורת המנהרה והקישור, הוא מה שמחזיק את התור הזה בחומרה שאתם מנהלים ולא במאגר של מישהו אחר.
תורים הוגנים וניהול תורים אקטיבי עוזרים גם בלי מחלקת קול, כי הם מונעים מזרם מגושם אחד למלא את המאגר. CAKE בלינוקס מאחד עיצוב, הוגנות לכל זרם ומחלקות Diffserv אופציונליות ב-qdisc אחד, ומנהל הרשת הפרוס צריך להחזיק בתצורה הזו ולא בהתקנת תור מתחרה שנייה. בלי עיצוב, מחלקה שמעל לתעבורה מגושמת עדיין ממתינה מאחורי מאגר שכבר מלא.
טיפול בתעבורה נכנסת אינו חסר תועלת, אבל הוא פועל אחרי שהמנות חצתה את קישור הקליטה. הוא יכול להשפיע על שולח מגיב ואינו יכול להחזיר השהיה שכבר הוצאה במעלה הזרם, ולכן הוא הקלה ולא ערובה.
| Stage | What you can control | What to verify |
|---|---|---|
| Application to client | Which flows are trusted for marking | The marked packets are the ones you intended |
| Tunnel boundary | Whether the inner mark is copied outward | Outer header carries the expected value |
| Your uplink | Shaping rate and class treatment | Queue counters move for the voice class |
| Provider path | Almost nothing | Whether the service enforces the marking at all |
| Receiving side | Local policy after arrival | Delay that is already in the past |
מה שורד באינטרנט הציבורי
ארכיטקטורת Diffserv מתארת טיפול בתוך דומיינים מנהליים, ולכן ספק עשוי להתעלם מסימון בגבול או לכתוב אותו מחדש. הטענה ההפוכה, שכל רשת תמיד מסירה אותו, חסרת ביסוס באותה מידה. השאלה הכנה היא למה הנתיב המסוים הזה מחויב בחוזה ומה נאכף בו. בדקו זאת עם בדיקה מסומנת במקום לחזור על כלל שקראתם במקום כלשהו.
שאלו מה הספק עושה עם המחלקה, ואז מדדו. סימון שנשמר אבל לא מתוזמן הוא קישוט; נתיב שמתזמן בלי לראות את הסימון הוא בעיה אחרת, והשניים צריכים תיקונים שונים.
תוכנית מדידה שמבודדת את השלב
בצעו שיחה רגילה אחת עם העלאה מתחרה מבוקרת, ואז חזרו עליה בקישור קווי. הסתכלו מה השיחה איבדה, מה רשמו מוני המחלקה וכמה קרוב הממשק פועל לגבול האמיתי שלו ולא למהירות הכותרת של התוכנית.
tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.netאם מונה מחלקת הקול נשאר באפס, הסיווג או העתקת הסימון שבורים ושום עדיפות לא תעזור. אם מונה המחלקה זז מקומית בעוד ההשהיה ממשיכה לעלות, צוואר הבקבוק נמצא מעבר לשער שלכם. אף אחד משני התוצאות לא מתוקן על ידי העלאת ערך העדיפות.