הממשק פעיל אבל wg-quick נכשל: מה עושים עכשיו
יחידה שנכשלה יכולה להשאיר מאחוריה מנהרה מוגדרת חלקית. קראו את השלב הראשון שנכשל, החליטו אם לנקות או לתקן, ואז הוכיחו זאת בבקשה.
היחידה אדומה, הממשק קיים, והמנהרה עובדת ברובה, וזהו השילוב המבלבל ביותר שיש. ההגדרה היא רצף: תחילה נוצר הממשק, ואחר כך מגיעים כתובות, מסלולים, הגדרות הפותר וכל פקודות וו. כשל בשלב הרביעי משאיר את שלושת הראשונים במקומם, ולכן שם הממשק הוא הוכחה שההפעלה החלה, לא שהיא הסתיימה. עובדה נוספת אחת הייתה חוסכת את הבלבול: השלב שנכשל.
מצב חלקי הוא הכשל הרגיל
את ההתנהגות הזו כדאי לצפות ולא להתייחס אליה כאל קלקול. הממשק הוא החלק הזול ביותר בהגדרה והקל ביותר להשאיר מאחור, והוא גם החלק שגורם למכונה להיראות חצי עובדת.
מה שעוד לא קיים הוא כל מה שבא אחרי השלב שנכשל. אם הכשל היה בשלב הפותר, הכתובות והמסלולים קיימים ו-DNS לא. אם זה היה מסלול, למנהרה יש כתובת ואין שום נתיב דרכה.
התוצאה היא מכונה שעונה לחלק מהבדיקות ונכשלת באחרות, ולכן אנשים מסיקים שהשירות מהבהב כשהוא כלל לא עלה בהצלחה. שירות שמעולם לא הסתיים לא יכול לההביב. הוא יכול רק להיכשל שוב ושוב מאותה סיבה.
מצאו את השלב הראשון שנכשל
קראו את היומן של היחידה ולא רק את המצב הנוכחי, וקראו אותו מתחילת הריצה שנכשלה. השורה האחרונה אומרת לכם את קוד היציאה; השגיאה הראשונה אומרת מה לתקן.
הפקודות האלה מדפיסות את מצב היחידה, את יומן האתחול של אותה יחידה ואת מצב המנהרה החי:
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0שגיאת פותר, מסלול שכבר קיים, וו שיצא עם קוד שאינו אפס וכשל בפענוח התצורה מופיעים כולם באותו חלון, וכל אחד מהם נוקב בשם הרכיב שלו. ניחוש מתוך מצב הממשק בלבד מתעלם מכל המידע הזה.
שלושה תנאים שמכריעים את התיקון
החליטו אם אתם מנקים, מתקנים במקום או מסירים את היחידה מנתיב האתחול, והחליטו זאת לפני שאתם מקלידים משהו.
אם הממשק שבור אבל התצורה נכונה, נקו והתחילו מחדש. אם התצורה שגויה, תקנו אותה ובכל זאת נקו קודם, כי הפעלת מנהל שני מעל מצב חלקי יוצרת שני בעלים לממשק אחד. אם הכשל הוא רכיב מערכת חסר, כמו עוזר פותר שאין למכונה, התקינו או הסירו את התלות במכוון במקום לערוך את היחידה עד שהיא תפסיק להתלונן.
שלושת המקרים האלה מכסים את רוב מה שנראה כמו יחידה אדומה מסתורית. השאלה המבחינה היא אם אותו כשל היה מתרחש במכונה עם מצב נקי, והתשובה מגיעה בדרך כלל משורת השגיאה הראשונה.
נקו לפני שניסיתם שוב
ניסיון חוזר מעל מצב קיים עלול להיכשל מסיבה חדשה ולהסתיר את המקורית. הורידו את הממשק בכלי שכלל יצר אותו, ואחר כך ודאו שלא נשאר דבר.
אל תמחקו ממשקים לא קשורים ואל תאפסו את מחסנית הרשת של המארח. שניהם פעולות גדולות לתיקון עצם קטן, והם הופכים מנהרה כושלת אחת למכונה שחיבורים אחרים שלה דורשים הקמה מחדש. ההיקף הנכון הוא ממשק אחד והיחידה שמחזיקה אותו. כל דבר רחב יותר דורש סיבה כתובה לפני שהוא קורה.
הוכיחו את המנהרה, לא את היחידה
יחידה ירוקה פירושה שרצף האתחול יצא עם אפס. זה לא אומר שחבילה הגיעה לצד השני, וזה לא אומר שהפותר הוגדר כפי שהתכוונתם.
שלחו בקשה דרך המנהרה וקראו את המצב שהפיק אותה:
systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.netלחיצת יד בלי תשובה עדיין אומרת לכם שהמנהרה נוצרה ושהצד המרוחק שותק, וזו בעיה אחרת מיחידה שמעולם לא עלתה. שמרו את מצב היחידה, את לחיצת היד ואת תוצאת הבקשה ברשומה אחת, כי הם נכשלים בנפרד ורק השילוב מתאר את המערכת.