למה vpnc מתנתק אחרי 24 דקות ומה לשנות

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

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

איזה טיימר מחזיק בנפילה

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

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

מקרה ראשון: הלקוח מוותר על הפעלה סרק

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

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

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

מקרה שני: חידוש המפתחות נדחה

אם המרווח שורד את שינוי ה-DPD, חידוש המפתחות של שלב 1 הופך למועמד. גרסאות vpnc ישנות טיפלו בחידוש בפחות זהירות מהנוכחיות, וקבוצת Diffie-Hellman היא המחלוקת הרגילה. כפיית קבוצה שהקצה הראשי כבר מקבל עולה שורה אחת וחיבור מחדש אחד, מה שהופך אותה לניסוי זול ולא לשינוי מדיניות.

IKE DH Group dh5

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

מקרה שלישי: תרגום משכתב את העטיפה

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

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

פרופיל שמתחבר היטב משורת הפקודה אבל לא משולחן העבודה הוא בעיית ממשק, לא בעיית טיימר.

אמת את ההחלפה שנכשלת לפני השינוי השלישי

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

vpnc --debug 3 office

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