למה הפגיעה של VPN נראית חמורה יותר ברשת סלולרית מאשר ב-Ethernet
שתי רשתות גישה ושני מצבי מנהרה נותנים ארבעה מספרים. מלאו את המטריצה, שמרו על שני השברים ותנו לתבנית לבחור את המדידה הבאה.
אותו מחשב נייד, אותו שרת ואותה מנהרה יכולים לאבד חמישית מתפוקתם ב-Ethernet ושלושה רבעים ברשת הסלולרית, ואף אחד משני המספרים אינו אומר ש-VPN שבור. כל רשת גישה מספקת נתיב אחר, והמנהרה מוסיפה נתיב שני מעליו. השוואה בין מספר אחד עם מנהרה למספר אחד בלי מנהרה אינה עונה על דבר, משום ששני המספרים מתארים מכנים שונים. ארבעה תאים ושבר שימור אחד לכל שורה יגידו לכם איזו שאלה לשאול הלאה.
ארבעה תאים, לא עונש אחד
מדדו את קו הבסיס הישיר ואת התוצאה עם מנהרה בכל רשת גישה, ושמרו אותם כמטריצה ולא כפסק דין אחד. קו הבסיס הוא אותה משימה שבוצעה באותה רשת בלי המנהרה; התוצאה עם מנהרה היא אותה משימה איתה.
| Access network | Direct baseline | Same task through the tunnel |
|---|---|---|
| Ethernet | E0 | E1 |
| Cellular | C0 | C1 |
השתמשו בעומס עבודה מורשה לבדיקות הישירות ושמרו על בקרות הפרטיות שהסביבה דורשת. בדיקה שמפרה את המדיניות מפיקה מספר שאינכם יכולים לפרסם ושאין לחזור עליו.
החזיקו את המשתנים במקום
החזיקו את המכשיר, היישום, היעד, כיוון ההעברה ונקודת הקצה של VPN קבועים בכל ארבעת התאים. אם שירות מחליף בשקט את שרת הבדיקה שלו בין ריצות, רשמו את השינוי והתייחסו לזוג כלא מבוקר במקום להחליק את ההפרש בממוצע.
חזרו על המטריצה בשני הכיוונים ובשעות דומות של היום. תנאי הרדיו הסלולרי והעומס בתא שלו משתנים בתוך דקות, ולכן קו בסיס אחד טוב במיוחד עלול להפריז בעונש הנראה. רשמו את הפיזור של התוצאות לצד ערך מייצג, וציינו אם ריצות המנהרה היו משולבות בקווי הבסיס או בוצעו בבלוק.
השילוב חשוב יותר ממה שרוב האנשים מצפים. קו בסיס שנמדד לפני הצהריים וריצה עם מנהרה שנמדדה אחר כך הם שתי רשתות שונות עם אותו שם.
השאירו את המכנה גלוי
דווחו על שבר השימור וגם על הקצב המוחלט: E1 חלקי E0, ו-C1 חלקי C0. קישור מהיר ששומר על חלק קטן מהתפוקה שלו וקישור איטי ששומר על רובה הם ממצאים שונים, ורק השבר מראה את ההבדל.
התפוקה המוחלטת עדיין קובעת מה משתמש יכול לעשות. השבר קובע לאן להסתכל. כש-Ethernet שומר על רוב קו הבסיס שלו והרשת הסלולרית על הרבה פחות, המשתנה המעניין נמצא בנתיב הסלולרי ולא בתוך ההצפנה.
שני המספרים שייכים לדוח, מפני שכל אחד מהם לבדו תומך במסקנה שהנתונים אינם תומכים בה.
קראו את התבנית לפני שמשנים משהו
תקרות דומות עם מנהרה בשתי הרשתות מצביעות על משהו משותף: נקודת הקצה, המעבד שלה, מגבלת קצב או קפיצה אחת עמוסה. ירידה שמופיעה רק ברשת הסלולרית מצביעה על הנתיב של אותה רשת, על האובדן, על ההשהיה ועל גודל החבילה האפקטיבי.
אלה רמזים ולא אבחנות, וההבדל הזה חשוב כשכותבים את הפנייה. תקרה משותפת לא תשתפר כשמחליפים את המודם הסלולרי, וירידה סלולרית בלבד לא תשתפר כשמשנים את גודל נקודת הקצה. ציינו איזו משתי התבניות ראיתם לפני שאתם מציעים שינוי. כך השינוי נושא תחזית, והמדידה הבאה יכולה לאשר אותה או להרוג אותה.
ההנחיות של OpenVPN עצמה לביצועים מפרידות בין מגבלות רוחב פס, מעבד, תעבורה וגודל חבילה על אותם קווים, וזו תזכורת שימושית לכך שהמנהרה היא לעתים רחוקות משתנה אחד.
כשגודל החבילה הוא החשוד
העיגול צורך מקום חבילה, ולכן הגודל האפקטיבי בנתיב סלולרי יכול להיות קטן מזה שהממשק מכריז עליו. שמרו ראיות לגבי גודל החבילה בנתיב שאתם משווים במקום להניח ערך משם טכנולוגיית הגישה.
Datagram packetization-layer path MTU discovery מתאר גילוי של הגודל האפקטיבי ולא קידוד קשיח שלו. השתמשו בתצפיות שהמימוש תומך בהן, ואל תדחפו MTU נמוך שרירותי לכל לקוח כאמצעי זהירות, מפני שזה מחליף בעיה אחת בבעיה גרועה יותר בנתיבים שהיו תקינים.
השערה לגבי גודל זקוקה לראיות משלה: אותה העברה בשני גדלים, עם תבנית האובדן מתועדת.
הוסיפו משתנה אחד בכל פעם
השוו תעבורה חלופית רק אחרי שמטריצת קו הבסיס נשמרה. כך נשאר משחק עם משתנה מכוון אחד, וזה מאפשר לייחס את השינוי ולא לנחש אותו.
החזיקו את כיול המטען של TCP בנפרד מההתנהגות של דטגרמות UDP, מפני ששניהם מגיבים אחרת לאובדן ולגודל הנתיב. שיפור שמגיע משינוי תעבורה הוא ראיה על אותה תעבורה, ולא הוכחה שההצפנה או הכיסוי היו הסיבה המקורית.
סדר העבודה: מלאו את ארבעת התאים, חשבו את שני השברים, שלבו את הריצות, ואז בחרו השערה אחת ובדקו אותה בשינוי אחד. כל דבר אחר הוא השוואה בין שני לא נודעים.