P_CONTROL_HARD_RESET_CLIENT_V2 ביומן: האם זו שגיאה?

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

קוד הפעולה מציין מקום בפרוטוקול

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

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

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

מה הלקוח באמת עושה באותו רגע

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

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

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

היכן מתחבא הכשל האמיתי אחרי האיפוס

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

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

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

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

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

מדוע כיבוי האימות הוא הרפלקס השגוי

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

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

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