קיפאון של שתי שניות: VPN או Wi-Fi?
עצירה של שתי שניות והפעלת VPN חדשה הם שני אירועים שונים. הציבו את נתיב הגישה והמנהרה על צירי זמן נפרדים לפני שמשנים טיימר.
קיפאון של שתי שניות שמתאושש מעצמו נראה זהה בין אם המנהרה ניהלה משא ומתן מחדש ובין אם הרדיו מעד. ייתכן גם שדבר לא נפל כלל, וכדאי לבדוק את האפשרות הזו קודם. פרץ אובדן קצר, משא ומתן מחדש ועצירה של יישום מרגישים אותו דבר לאדם שליד המקלדת. רק אחד משלושת המקרים מתוקן על ידי עריכת תצורת המנהרה.
שני רישומים, לא אחד
רשמו מה קרה לחיבור שמתחת, ובנפרד מה עשתה המנהרה עצמה. אחר כך הציבו את ההפסקה של היישום מול שני הרישומים. אלה סדרות אירועים בלתי תלויות שלעיתים חופפות, וקריאה לשלושתם ניתוק מניחה את התשובה כבר בהתחלה.
צג שבודק פעם בדקה אינו יכול לראות הפרעה של שתי שניות. לדווח שהיום ההוא היה תקין זה נכון טכנית וחסר תועלת מעשית. שימו את מרווח הדגימה ליד כל תוצאה שאתם מצטטים.
מה עשה קישור הגישה בזמן שהיישום קפא
מרווח הדגימה ופרק הזמן קובעים מה הצג יכול היה לראות בכלל, לכן רשמו את שניהם לצד התוצאה. היעדר מתועד של הפרעות אומר מעט כשהמכשיר דוגם כל שישים שניות. אחר כך בדקו שלושה מקומות עם חותמות זמן: הנתב המקומי, מארח חיצוני מאושר שנגיש דרך הנתיב הפשוט, ומשאב מאחורי המנהרה.
אשרו קודם את המסלולים, מפני שיעד ציבורי יכול בעצמו להיות מנותב דרך המנהרה ואז הוא מודד את המנהרה ולא את נתיב הגישה. הראיות שמתארכות באמת את הניתוק נמצאות שכבה אחת למטה: אירועי קישור בנתב, רישומי סנכרון מחדש במודם, וכתובת WAN שהשתנתה. מונה שגיאות מצטבר אומר לכם שמשהו השתבש, אבל אף פעם לא מתי. קשרו את הרישומים האלה לחלון התקרית במקום לקרוא אותם בבידוד.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showמונה שעלה אתמול אינו מסביר דבר על קיפאון הבוקר. הגבילו את המתאם לחלון שהמשתמש דיווח עליו.
חפשו את רישום האתחול מחדש
דאטגרם UDP שאבד אינו גורם מעצמו ל-Community OpenVPN לפתוח במשא ומתן TLS חדש. התנהגות האתחול מחדש עוקבת אחרי ping-restart, וייתכן שהשרת כפה את הערך הבתוקף; המדריך ל-2.6 מגדיר את הטיימרים האלה. המסירה נשברת לרגע, הסף לא נחצה אף פעם, והיומן נשאר ריק. לכן חפשו ביומן סביב ההפסקה שורת אתחול מחדש, חיבור חדש או מזהה הפעלה שהשתנה. אם אף אחד מהשלושה לא מופיע, המנהרה כנראה לא עשתה דבר והטיימר מעולם לא היה הבעיה.
קיצור כל keepalive גורם לגילוי להיראות מהיר יותר ומזיז את הקו שבו מעידה קטנה הופכת לחיבור מחדש. כל חיבור מחדש עולה סבב אימות והתקנה מחדש של מסלולים. מתיחת הטיימר לא קונה דבר מלבד חלון ארוך יותר שבו נתיב מת עדיין נראה חי. שניהם החלטות כוונון עם מחיר, לא שיפורים בחינם.
גם אירוע נעדר הוא ראיה, וזה בדיוק הסוג שאנשים מדלגים עליו מפני ששום דבר ביומן לא מפנה אליו תשומת לב. רשמו את החיפוש שערכתם, לא רק את תוצאתו.
תנו להשוואה להחליט מה לתקן
כששני הרישומים זה לצד זה, הייחוס בדרך כלל נכתב מעצמו. אירוע קישור בנתב בשני הנתיבים פירושו שנושא הדיון הוא חיבור הגישה. מנהרה שקטה ונתיב פשוט שמיש פירושם שהנושא הוא המשא ומתן.
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
כל שורה היא רמז, לא פסק דין: נקודות קצה מנמיכות את עדיפות ICMP, ושתי יעדים לא בהכרח חולקים נתיב אחד. שמרו על סנכרון השעונים בין הלקוח, השער והיישום כדי שההשוואה תהיה אפשרית בכלל. שורה שמתאימה לשתי עמודות זקוקה לתצפית נוספת, לא להחלטה.
דוח שעומד בסקירה עונה על ארבעה דברים: כמה זמן נמשך הקיפאון, אילו נתיבים המשיכו להגיב, מה היומן רשם באותה שנייה, ובאיזו תדירות הצג דוגם. ארבע העובדות האלה מאפשרות לקורא הבא לשחזר את התצפית במקום לסמוך על סיכום. אחוז זמינות מסתיר בדיוק את המרווח שמעניין אתכם, וכך גם הביטוי "ה-VPN נפל".