למה ה-VPN שלך נופל בכל פעם שהמפתחות מתחלפים
מנהרה שמתה לפי לוח זמנים נכשלת בדרך כלל בחילופי החידוש, לא בלחיצת היד הראשונית. השווה הצעות, פרטי זיהוי ומצב החלפה.
החיבור עובד שעה ואז מת, והלקוח לא מדווח על משהו שימושי יותר מ-disconnected. אותה תקופה היא הרמז, כי משהו בחילופי החידוש שונה מלחיצת היד הראשונית. הטיימר רק קובע מתי תיתקלו בו. שמרו את ההודעות מאותו חילוף במקום את התווית הסופית.
קראו את השלב, לא את התווית
ב-IKEv2 אגודת ה-IKE ואגודת ה-CHILD מתחדשות לפי לוחות זמנים נפרדים. הצעה שהייתה מקובלת למשא ומתן הראשון אינה מקובלת אוטומטית לשני. אחת יכולה להסתיים בעוד השנייה נדחית, מה שיוצר מנהרה שקיימת חצי. תעדו את החילוף בכלי שבבעלותו במקום בשורת יומן של הלקוח:
swanctl --list-sas
swanctl --log --level 2
ip xfrm state list
עבור OpenVPN, האירוע המקביל הוא משא ומתן חוזר שנשלט על ידי הגרסה והגדרות הפריסה. להתנהגות האימות שלו יש מצבי כשל משלו. ההודעה שחשובה מציינת את השלב שנכשל, ועליכם לתעד אותה מילה במילה במקום לנסח אותה מחדש בכרטיס.
רשמו גם את חותמות הזמן. נפילה במרווח קבוע אחרי המשא ומתן המוצלח האחרון היא ממצא שונה לגמרי מזו שמגיעה באקראי במהלך השימוש, ולעיתים קרובות המרווח הוא הראיה היחידה ששורדת.
השוו את ההצעה שנכשלת
הצעה שנדחתה מייצרת הודעה ברורה בצד המשיב. הסיבה הרגילה היא הבדל בין שני הקצוות באלגוריתם, באורך המפתח, בקבוצה או בתוקף. משא ומתן ה-CHILD הראשוני אולי הצליח כי הצד השני יזם אותו, כלומר השתמש ברשימת ההצעות של הצד השני. הסתכלו על שני הקצוות לפני שמשנים משהו.
אי-התאמות בתוקף ראויות לתשומת לב מיוחדת, כי ערך שנראה נדיב בקצה אחד יכול לגרום לקצה השני להתחיל חידוש שאינו יכול להשלים. התיעוד של התנהגות החלפת המפתחות מתאר כיצד מופעל חידוש האגודה וכיצד שני הקצוות יכולים להיות שונים בציפיות הזמן שלהם. השוו את מה שכל קצה מצהיר שהוא תומך בו ולא את מה שקובץ התצורה מרמז.
פרופיל ישן או תבנית של ספק יכולים לנעוץ הצעה שהגרסה הנוכחית כבר לא מציעה. אי-ההתאמה מתגלה רק כשמשא ומתן חדש נכפה.
הפרידו בעיית פרטי זיהוי מעמית בלתי נגיש
חידוש שנכשל באימות נראה דומה בלקוח ושונה לחלוטין בשרת. אם פרט זיהוי נבדק מחדש במשא ומתן החוזר, תעודה שפגה, חשבון שבוטל או סיסמה שהשתנתה ייצרו נפילה בדיוק במרווח החידוש, בעוד כל חיבור קודם הצליח. עמית בלתי נגיש הוא האפשרות השלישית, והוא לא מייצר שום דחייה: החבילות יוצאות ולא מגיעה תשובה. מקרה זה עוקב בדרך כלל אחרי שינוי רשת ולא אחרי טיימר, אז בדקו אם הכשל מגיע אחרי נדידה, תקופת חוסר פעילות או שינוי מסלול.
הבחינו בין השלושה לפי מה שהקצה הרחוק תיעד. דחייה עם סיבה, כשל אימות ושתיקה הם שלושה תיקונים שונים. הפעלה מחדש של הלקוח ממוטטת אותם לתצפית אחת חסרת תועלת.
בדקו את תאריכי התעודה ומצב החשבון לפני שמאשימים את הרשת. שניהם זולים לבדיקה ושניהם בלתי נראים בהודעה של הלקוח עצמו.
כפו חידוש אחד וקראו את התוצאה
כפו חידוש אחד בשיטה הנתמכת על ידי המפעיל במקום לחכות שעה לבא. שמרו על מדיניות הכשל הנדרשת שלמה בזמן שאתם עושים זאת. כיבוי האימות או מתיחת התוקף ליום גורמים לתסמין להיעלם מהלוגים שלכם בלי לתקן דבר. זה גם משאיר הפסקה ארוכה יותר שמחכה לאדם הבא.
לאחר שהתיקון במקום, בדקו את המנהרה המחודשת ואז שלחו בקשה חדשה מהאפליקציה. הפעלה של אפליקציה שהייתה חיה כשהאגודה השתנתה עשויה להזדקק לשחזור משלה למרות שהמנהרה שוב בריאה. משתמשים ידווחו על כך כ-VPN שעדיין שבור.
תעדו את גרסאות השחרור, את הטיימרים שנקבעו במשא ומתן ואת השלב שנכשל. ההישנות הבאה תוכל אז להיות מושווית לזו במקום להיות מתוארת שוב מהזיכרון.