למה ה-VPN שלי כל כך איטי? בדקו את ארבעת הקטעים האלה

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

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

החליטו מה פירוש איטי לפני שמדדים

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

בלי הרשומה הזאת, כל השוואה מאוחרת הופכת לוויכוח על רשמים.

בדקו קודם את רשת הגישה

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

ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin

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

החליפו את היציאה, ואז את התעבורה

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

כאשר השירות מספק את שני הפרופילים, השוו OpenVPN מעל UDP עם OpenVPN מעל TCP. UDP היא נקודת הפתיחה המקובלת לעבודה אינטראקטיבית, בעוד TCP יכול לעזור ברשת גישה שאינה מעבירה תעבורת UDP כלל. מנהרת TCP משחזרת אובדן על ידי שליחה מחדש בתוך הזרם, ולכן היא עשויה להרגיש איטית יותר בקישור שמפיל חבילות, וכן הערות פתרון בעיות הביצועים של OpenVPN מכסות את אותו פשרה לפני שתכווננו משהו אחר. שינוי המילה "udp" ל-"tcp" בפרופיל אינו יכול ליצור מאזין שהשרת לא פתח מעולם.

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

קראו את המכשיר ואת הסימפטום יחד

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

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

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