מעקב אחורה של שידור חוזר ב-OpenVPN ביומן: מה השורה אינה מוכיחה

השורה אומרת PID_ERR replay-window backtrack occurred, וכל תוצאות החיפוש מסבירות אותה כמנות שנפלו ומנהרה שבורה. בנתיב ה-UDP של Community OpenVPN 2.6, ההודעה נכתבת בזמן שפונקציית הקליטה עדיין מחליטה מה לעשות עם המנה. היא רושמת שיא חדש של מעקב אחורה, ואז אותה פונקציה משווה את המרחק לחלון ולמצב שנרשם לפני שהיא מקבלת או דוחה. לקרוא את תווית היומן כפסק הדין היא הטעות שצ'ק-ליסט זה קיים כדי למנוע.

שלב ראשון: זהו מהי השורה

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

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

שלב שני: מצאו את התוצאה עבור אותה מנה

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

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

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

שלב שלישי: החליטו אם הסדר מחדש אמיתי

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

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

שלב רביעי: פרמטרי החלון, ומה הם אינם

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

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

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

mute 20
replay-window 64 15

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

שלב חמישי: בדקו את הנתיב שחשוב למשתמש

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

רשמו מה מדדתם בכל שלב. הרשומה היא מה שמונע מהדיווח הבא להתחיל שוב בשורה המפחידה ולעבוד ממנה החוצה.

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