VPN נופל בזמן העלאות גדולות: קודם קראו את התור
תור יציאה רווי מעכב תעבורת בקרה בדיוק כמו יישומים. השוו התנהגות במנוחה ובעומס, אחר כך שנו דבר אחד וחזרו על הבדיקה.
המנהרה יציבה כל היום ואז נופלת בכל פעם שמתחילה העלאה גדולה. בקשות אינטראקטיביות נתקעות ראשונות, הלקוח מדווח על פסק זמן, והחיבור חוזר כשהעברה מסתיימת. התבנית הזאת מצביעה על תור ועיבוד ולא על שרת מרוחק שקרס, כי לשרת מעולם לא ניתנה ההזדמנות לענות בזמן. העבודה היא לשחזר את זה תחת עומס מבוקר ולקרוא את המונים הנכונים.
שנו משתנה אחד בכל הרצה והשאירו את נקודת הקצה קבועה.
בנו השוואת עומס שאפשר לחזור עליה
רשמו קו בסיס כשהקישור במנוחה: זמן הליכה וחזרה, כמה בקשות יישום ויומן האירועים של המנהרה עצמה. אחר כך התחילו העלאה בגודל ידוע וחזרו בדיוק על אותן מדידות בזמן שהיא רצה. השאירו את נקודת הקצה, הלקוח ויעד הבדיקה ללא שינוי, כי שינוי של שניים מהם בבת אחת לא אומר לכם דבר.
שימו לב איזה אירוע מופיע ראשון. עלייה בזמן ההליכה והחזרה לפני כל שגיאה מרמזת על תור; פסק זמן חד עם השהיה יציבה מרמז על משהו אחר, כמו החלפת מפתחות או פעולה בחשבון. שתי התבניות מובילות לצעדים הבאים שונים. רשמו את התצפית לפני שאתם משנים משהו.
שמרו את הפלט עם חותמות זמן כדי שאפשר יהיה להשוות את ההרצה תחת עומס ואת ההרצה במנוחה שורה אחר שורה.
קראו את התור, לא את המהירות
קישורי צרכנים מאחסנים מנות בציוד של הספק, ותור יציאה מלא מעכב הכול, כולל מנות הבקרה הקטנות שמחזיקות מנהרה בחיים. בדיקת מהירות שמדווחת על מספר גבוה אומרת מעט על העיכוב הזה, ולכן בדיקה במנוחה עוברת בעוד קישור רווי נכשל.
ping -c 20 -i 0.2 203.0.113.10 mtr -rwc 20 203.0.113.10 tc -s qdisc show dev eth0 ss -ti dst 203.0.113.10 nstat -az | grep -E 'Retrans|Timeout'
השוו את מספרי ההשהיה תחת עומס לאלה שבמנוחה. קפיצה מעשרות מילישניות למאות, בלי אובדן מנות, היא תור; אובדן עם השהיה יציבה מצביע על תקלה אחרת.
בדקו את ההתקן ואת נתיב הבקרה
הצפנה והעברה עולות זמן מעבד, ונתב קטן או מחשב נייד שמוגבל בחום עלול להפיל מנות בזמן שהוא עסוק. הביטו בעומס הכולל ולא באחוז של תהליך אחד, כי העברה בגרעין וטיפול בפסיקות לא מופיעים במקום שאנשים בדרך כלל מסתכלים בו.
uptime mpstat -P ALL 1 3 dmesg | grep -i -E 'thermal|throttl' journalctl -u openvpn-server@server --since '10 min ago' | tail -20
פסק זמן בלקוח יכול גם לחפוף עם החלפת מפתחות מתוזמנת או עם אירוע של מדיניות הפעלה. קראו את היומן של הלקוח עצמו לסדר האירועים, ולא רק את הודעת השגיאה של היישום.
שנו דבר אחד וחזרו
במקום שהפלטפורמה תומכת בכך, הגבילו את קצב ההעלאה או סווגו תעבורת גוש מתחת לתעבורה אינטראקטיבית כדי שהתור לא יתמלא לעולם. אחר כך חזרו על אותו עומס עבודה והשוו את אותם שלושה מספרים כמו קודם. שינוי שמשפר בדיקת מהירות אבל משאיר את פסק הזמן במקומו לא תיקן דבר.
העלאת פסקי זמן בכל מקום והחלשת ההצפנה הם שני השינויים שגורמים לתסמין להיעלם בלי לזהות איזה גבול נכשל. אף אחד מהם אינו תיקון. שניהם מזיזים את הכשל מאוחר יותר, במקום שבו קשה יותר לייחס אותו.
סיימו בבדיקת בקשה חדשה ובהתנהגות ההתחברות מחדש שהמשתמש באמת נשען עליה. יציבות תחת העומס שגרם לתלונה היא התוצאה היחידה ששווה לתעד.