העלאה ב-VPN איטית יותר מהורדה? קבעו איזו מגבלה אתם פוגשים

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

שלוש מגבלות שנראות זהות מסרגל ההתקדמות

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

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

מדדו כיוון אחד בכל פעם

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

iperf3 שולח מהלקוח כברירת מחדל, ולכן הריצה הפשוטה מודדת את נתיב ההעלאה שלכם; -R הופך את הכיוון ומודד הורדה. הריצו אותן בהפרש של כמה דקות ורשמו את שני המספרים במקום לחשב ממוצע:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

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

החליטו לפי היכן ההעלאה משתנה

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

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

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

כשתקיעה מנצחת איטיות

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

בדקו את הנתיב עם מטען שאסור שיתפצל, ואז השוו את ה-MTU של ממשק המנהרה לערך שעובר:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

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

מה לשנות ומה להשאיר

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

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