ה-VPN מתנתק באותו פרק זמן? התאימו את הטיימר
נפילה בפרק זמן קבוע היא טביעת אצבע. השוו את חידוש המפתחות של המנהרה, טיימר חוסר הפעילות של NAT, חכירת DHCP ומגבלת החשבון לפני שתשנו משהו.
מנהרה שמתה כל חמש עשרה דקות, או כל שעה באותה דקה, אומרת לכם שפג טיימר כלשהו, ולא שהרשת לא יציבה. הצעד המועיל הוא לרשום את פרק הזמן ולהשוות אותו לארבעת הטיימרים שיוצרים את התבנית הזו. שינוי הזמנים לפני ההשוואה הזו בדרך כלל מזיז את התקלה בלי להסביר אותה, מה שהופך את ההופעה הבאה לקשה יותר לקריאה מהראשונה. המדידה עולה עשר דקות ומחליפה שבוע של ניחושים.
הפכו את פרק הזמן למספר
אספו חמישה או שישה מקרים וחשבו את הפער ביניהם, לא את הפער מתחילת היום. נפילה ב-09:12, 10:12 ו-11:12 היא גבול שעתי; נפילה ב-09:12, 09:27 ו-09:42 היא חמש עשרה דקות מהחיבור המוצלח האחרון. עגלו את התוצאה לטיימר הסביר ביותר, לא לדקה הקרובה ביותר.
רשמו שני רגעים לכל אירוע: מתי התעבורה זזה לאחרונה ומתי הלקוח דיווח על הניתוק. הם שונים כאשר מתה מנהרה בשקט והלקוח מבחין בכך רק בשליחה הבאה, וההבדל הזה הוא מה שמפריד בין פסק זמן של חוסר פעילות לתקלה קשה. לקוח שמבחין מאוחר מנפח את חלון חוסר הפעילות שאתם מודדים.
שימו לב אם ההתחברות מחדש אוטומטית. לקוח שמתחבר מחדש בתוך שניות משאיר את פרק הזמן גלוי ביומן ומחוץ לדוח המשתמש, ולכן תקלות אלה מתוארות לעתים קרובות כמזדמנות ולא כמחזוריות. הוא גם מסתיר את האירוע מהאדם שמשתמש במחשב הנייד.
ארבעה טיימרים שנראים דומים
כמעט כל נפילה חוזרת של המנהרה מגיעה מאחד מאלה: חידוש מפתחות של הפרוטוקול, פקיעת מיפוי לא פעיל, אירוע DHCP או ממשק, או מדיניות חשבון. הם נבדלים בשאלה אם עברה תעבורה ובמה שהיומן אומר בגבול.
החתימות שלהלן שוות לימוד, מפני שהן מאפשרות לשלול שלושה הסברים משורת יומן אחת:
| Timer | Typical trigger | What the log shows at the boundary |
|---|---|---|
| Protocol rekey | Traffic present, fixed interval | Negotiation lines, sometimes a failure |
| NAT or firewall idle | No traffic for minutes | Silence, then a timeout on send |
| DHCP lease or link change | Half the lease, or a radio event | Address or interface churn |
| Account session limit | Wall-clock hours since login | Clean disconnect, server-side reason |
השורה הראשונה היא מנגנון אבטחה שעושה את עבודתו, והשנייה היא התקן ביניים ששוכח מצב. ערבוב ביניהם מוביל או להחלשת חידוש המפתחות או לרדיפה אחר כלל חומת אש שמעולם לא היה מעורב.
עסוק מול לא פעיל אומר לכם איזה חצי
בצעו השוואה מבוקרת עם תעבורה רציפה, כמו זרם ארוך למארח בתוך המנהרה, ובדקו אם פרק הזמן משתנה. אם הנפילה נעלמת בזמן שנתונים זורמים, הטיימר מבוסס על חוסר פעילות.
אם היא שורדת תעבורה רציפה, הגורם שייך לחידוש המפתחות, לחכירה או למדיניות. הבדיקה האחת הזו מסירה חצי מהמועמדים בכשעה של תצפית, והיא לא עולה דבר מלבד תשומת לב.
השאירו את רשת הגישה ללא שינוי במהלך הבדיקה. מעבר בין Wi-Fi ל-Ethernet באמצע ההשוואה מכניס בדיוק את אירוע הממשק שאתם מנסים להבדיל מטיימר.
התאימו את שורת היומן לגבול
קראו את יומני הלקוח והשרת סביב הרגע שנרשם, לא את כל הקובץ. חידוש מפתחות מראה משא ומתן; פקיעת חוסר פעילות לא מראה דבר עד החבילה הבאה; שינוי חכירה מראה עבודת כתובת; מגבלת מדיניות מראה בדרך כלל ניתוק מנהלי נקי.
הפקודות האלה שולפות את החלון הרלוונטי מכל מקור:
grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg showאם שלושת המקורות מסכימים על חתימת הזמן, יש לכם את הבעלים של הטיימר. אם רק ביומן הלקוח יש משהו, סביר להניח שהשרת אינו זה שמסיים את ההפעלה.
תקנו את השלב, לא את הסמל
לכל בעלים יש תיקון נתמך אחד. כשל בחידוש מפתחות דורש הצעות תואמות בשני הקצוות. פקיעת חוסר פעילות דורשת אות חיים או ציפייה קצרה יותר לחוסר פעילות, במגבלות שהנתיב מאפשר. אירוע חכירה דורש תיקון של הגדרות הממשק או החשמל. מגבלת חשבון היא החלטת מדיניות, לא באג.
כיבוי חידוש המפתחות או האימות כדי לשמור על סמל ירוק מחליף נפילה נראית בחולשה בלתי נראית, ומשאיר אתכם בלי יכולת לומר מתי המנהרה ניהלה משא ומתן אחרון על מפתחות חדשים. בדקו מחדש את המשך הזמן המקורי לאחר מכן ושמרו את חתימות הזמן, כדי שאפשר יהיה להשוות את האירוע הבא לזה במקום להתחיל מהתחלה.