למה gateway-ping-timeout באמת ממתין ב-NetworkManager

אתם מוצאים connection.gateway-ping-timeout בשרשור על מחשב נייד שעולה לפני שהרשת שמישה, מעלים אותו, ומשהו משתנה. אם השינוי עזר מהסיבה שאתם חושבים זו שאלה נפרדת. התשובה מתחילה במה שההפעלה עושה בפועל בזמן שהטיימר הזה רץ, ובכך שלהמתנה יש שתי סופות אפשריות.

עקבו אחר חיבור אחד משורת הפקודה והסמנטיקה נעשית מוחשית.

עקבו אחר הפעלה אחת

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

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

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

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

להמתנה יש שתי סופות

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

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

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

שני אובייקטים, הגדרה אחת

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

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

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

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

מה שההמתנה לא יכולה להעיד

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

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

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

אם משנים, כתבו למה

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

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

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