להבחין בין כשל אתחול של Pi ללא מסך לבין כשל רשת
אתחול, כתובת, האזנה ונגישות הם ארבעה תוצאות. בדקו איזה מהם נכשל לפני שהכרטיס יוצא, ועקבו אחרי מסלול התשובה לפני צריבה חוזרת.
הכרטיס יוצא מהמארז לפני שמישהו שאל איזה מארבעת הדברים באמת נכשל. ה-Pi הפסיק להגיב אחרי שינוי ב-VPN או ברשת, וצריבה חוזרת נראית כמו המהלך היחיד שנותר. לעיתים נדירות זה כך: החכירה יכולה לזוז, sshd יכול לעצור, או שהתשובה יכולה לצאת במסלול שאין לך דרך לעקוב אחריו, ולכל אחד מאלה יש תיקון משלו. העבודה המועילה היא להפריד בין מה שצפית בו לבין מה שהנחת.
ארבעה תוצאות, לא אחת
אתחול, כתובת, האזנה ונגישות הם ארבעה תוצאות נפרדות, וכל אחת מהן יכולה להיכשל בעוד האחרות עדיין תקפות. לוח יכול לעלות בצורה מושלמת ומעולם לא להופיע ברשת. הוא יכול להופיע בכתובת שאיש לא ציפה לה, או להחזיק בכתובת הנכונה עם SSH מכובה. הוא יכול להצליח בכל השלושה ועדיין להיות בלתי נגיש, כי התשובות יוצאות דרך השער הלא נכון.
הדחף לצרוב מחדש מכנס את ארבעת אלה לשאלה אחת, ולכן הוא לעיתים קרובות כל כך מייצר Pi עובד בלי שום הסבר למה בעצם נשבר.
היכן הראיות באמת נגמרות
רשמו שלושה דברים לפני שנוגעים במשהו: הכתובת והקישור למעלה שעבדו לאחרונה, מה שונה, והפעולה הראשונה שהפסיקה לעבוד. שם מארח שכבר לא נפתר, חיבור SSH שפג תוקפו, וחיבור TCP שנדחה הם שלוש תצפיות שונות שמצביעות על שלוש שכבות שונות. פינג שנכשל בודק נגישות של כתובת אחת ונכשל מכל הסיבות שלעיל, כולל לוח שמעולם לא עלה. לכן הוא לא יכול להחליף בדיקת אתחול.
אם יש תצוגה מקומית או קונסולת שחזור, השתמשו בה, כי השאלה שהיא עונה עליה היא אם המכונה מגיעה למערכת ההפעלה שלה. זו השאלה היחידה שצריבה חוזרת הייתה פותרת. אם הלוח נכשל לפני השלב הזה, פעלו לפי תיעוד השחזור של הפלטפורמה במקום להסיק תקלת חומרה מצילום מסך חסר, והפסיקו לנתק חשמל כאמצעי אבחון.
לשקם את מסלול הגישה במערכת פועלת
מצאו את הקישור והכתובת הנוכחיים דרך מי שמחזיק בתצורת הרשת, ואז השוו זאת לרשימת הלקוחות הנוכחית של הנתב ולכתובת שבה השתמש לקוח ה-SSH. שם מארח שמור או חכירת DHCP ישנה יכולים להצביע במשך שבועות ליעד של אתמול. אחר כך ודאו ש-sshd מופעל, מאזין בכתובת שקיימת, ומורשה מרשת הניהול. הנחיות ה-SSH של Raspberry Pi מתייחסות להפעלת השרת ולהתחברות לכתובת הנוכחית כשני שלבים נפרדים, והתקנה חדשה של Raspberry Pi OS משאירה את SSH כבוי כברירת מחדל.
שם מארח יכול להיות מופנה למכונה אחרת, ותמונה חלופית מגיעה עם המפתח שלה, לכן בדקו את טביעת האצבע דרך מסלול שאתם כבר סומכים עליו במקום ללחוץ ולהתעלם מהאזהרה. מחיקת האזהרה היא הדרך שבה שינוי כתובת זמני הופך לבעיית אמון קבועה. אם בקשת המפתח היא הסימפטום היחיד, מדובר בשאלת זהות ולא בשאלת נגישות.
לעקוב אחרי מסלול התשובה לפני שמאשימים את הלוח
VPN יכול לשנות את בחירת המסלול בזמן שהקישור הפיזי נשאר מקושר, וזה בדיוק המקרה שבו ה-Pi פועל, מאזין ובכל זאת אינו נגיש. הבקשה מגיעה והתשובה יוצאת דרך מנהרה שלקוח המנהל לא יכול לעבור בה. קונסולה מקומית ושקע מאזין לא מוכיחים דבר על מסלול החזרה, לכן ודאו איזה ממשק נושא את התשובה ואיזה שער הוא בוחר. השוו זאת לרשת שבה המנהל באמת נמצא, כי הכשל הזה מאובחן בטעות כלוח מת יותר מכל כשל אחר.
הבדיקה הזולה ביותר היא לראות את התשובה יוצאת: ב-Pi, שאלו איזה מסלול יישא את כתובת המנהל והשוו אותו לממשק שממנו הגיעה הבקשה. אי-התאמה שם מסבירה את כל הסימפטום ועולה פקודה אחת.
גבול אחד בכל פעם, ומתי צריבה חוזרת נכונה
תקנו את התצורה דרך הבעלים שלה אחרי ששמרתם את המצב הנוכחי. החלפת מנהל הרשת, ריקון חומת האש וניחוש כתובת סטטית הם שלושה שינויים שהופכים את התצפית הבאה לחסרת תועלת. אם הראיות מצביעות על המסלול או הסינון של ה-VPN, חזרו לשגרת העצירה או התיקון של אותו לקוח, ופעלו בתוך תוכנית השחזור המוסכמת; השוואה מבוקרת היא משהו אחר מלכבות הגנה במארח שלא הסברתם.
צריבה חוזרת היא בחירת שחזור מכוונת, שנעשית אחרי שהבנתם את הנתונים, את הזהות ואת השלב שנכשל. היא לא מה שהיעדר התחברות אמור להפעיל כברירת מחדל.
שמרו את רישום התצורה במקום שאפשר לקרוא בלי ה-Pi, ודרך חזרה שלא עוברת במנהרה שאתם עומדים לשנות. אחר כך עבדו לפי הסדר: ודאו את השלב מקונסולה מקומית, מצאו את הכתובת הנוכחית, בדקו את המאזין ואת המדיניות שלו, עקבו אחרי מסלול התשובה, ושנו דבר אחד. אם הלוח מעולם לא הגיע למערכת ההפעלה, תיעוד השחזור הוא הצעד הבא ולא הרשת.