ה‑VPN אומר שהוא מחובר, אבל נתיב ברירת המחדל מת
מעבר מ‑Wi-Fi ל‑Ethernet יכול להשאיר את הנתיב ואת הפותר על המנהרה הישנה. קראו את שני המצבים בנפרד, ואז תקנו את זה ששגוי.
הלקוח מדווח שהוא מחובר, הסמל במגש המערכת נראה רגיל, ושום דבר לא נטען. זה התחיל מיד אחרי שעברתם מ‑Wi-Fi לכבל, או מיד אחרי ששדרוג ההפצה הסתיים. מה שנשבר אינו הפרופיל אלא המצב שנבנה עבור חיבור הבסיס הקודם. לליבה עדיין יש נתיב ברירת מחדל שמצביע על התקן מנהרה שאיש אינו מחזיק בו, או שהפותר עדיין מפרט שרתים על קישור שנעלם. שני הכשלים נראים כמו רשת מתה ושניהם ניתנים לתיקון במקום.
החלקים המיושנים כבר היו שגויים לפני ששמתם לב. ניתוק כבל רק הפך אותם לגלויים.
שאלו את הליבה לאן תלך החבילה
רשימות נתיבים קשות לקריאה משום שהן מפרטות כל מה שהמערכת יודעת, כולל רשומות שכבר אינן תקפות. חיפוש נתיב עונה על השאלה היחידה ששווה לשאול: איזה התקן נושא את החבילה המסוימת הזו עכשיו. אם התשובה נוקבת בהתקן מנהרה, הליבה תשתמש בו גם אם אין מאחוריו תהליך לקוח חי, והחבילה נופלת לממשק שאיש אינו מתחזק. אם התשובה נוקבת במתאם Ethernet בזמן שהלקוח מתעקש שהוא מחובר, המנהרה קיימת אבל איבדה את הבחירה, וזו התוצאה הרגילה של מעבר מאלחוטי לחוטי.
הריצו את החיפוש פעמיים, פעם אחת לכתובת ציבורית ופעם אחת לכתובת פנימית, כי מדיניות מנהרה מפוצלת יכולה לנתב אחת ביושר ולהפיל את האחרת.
ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40הפותר גם שומר את הקישור המת
במארח עם systemd-resolved, שרתי DNS שייכים לקישורים ולא לרשימה עולמית אחת. קישור VPN שנפל יכול להישאר רשום עם השרתים שלו לזמן מה, ואז כל חיפוש ממתין לכתובת שלעולם לא תענה. העיכוב הזה מרגיש כמו רשת מתה והוא שולח אנשים להסתכל על נתיבים כשהנתיב תקין.
resolvectl status
resolvectl query intranet.example.comקראו את הבלוקים לפי קישור וזהו איזה קישור מחזיק בתחום המדובר. מנהרה שעולה אבל אינה הבעלים של התחום הפנימי מעבירה שמות פנימיים לפותר הציבורי, והתסמין אינו ניתן להבחנה מתקלת ניתוב.
תקנו את הרישום ולא /etc/resolv.conf. בהתקנות Ubuntu ו‑Fedora הנוכחיות הנתיב הזה הוא קישור סמלי למצב הריצה של הפותר, ולכן עריכה או מתעלמת או נדרסת באירוע הרשת הבא.
VPN לא מתחיל מעצמו לעולם
NetworkManager מעלה VPN מעל חיבור בסיס, והוא לומד איזה בסיס לעקוב אחריו לפי connection.secondaries על אותו בסיס. אסמכתת הגדרות החיבור אומרת במפורש שחיבור אוטומטי אינו מיושם עבור פרופילי VPN. זה כל המנגנון מאחורי סוג התקלה הזה: החליפו את הבסיס, וה‑VPN צריך להיות מותאם מחדש או מופעל ידנית.
nmcli device status
nmcli connection show --active
nmcli connection up office-vpnכשהרשימה הפעילה מציגה את הבסיס בלי ה‑VPN, המנהרה אינה פעילה כלל והנתיב מעולם לא הותקן ולא נשאר מיושן. כשההפעלה מתלוננת שאין חיבור מקור, הבסיס שאיתו היא הותאמה נעלם, אז תקנו קודם את הבסיס או את ההתאמה והפסיקו לנסות שוב את ה‑VPN.
שדרוג יכול להפיל הגדרות בלי הודעה
שדרוג הפצה מחליף את הלקוח ולעיתים קרובות את תוסף ה‑NetworkManager שלו, בעוד הפרופיל השמור שומר על שמות המאפיינים שאיתם נכתב. כל מה שהתוסף החדש כבר אינו מזהה מדולג בשקט. הפרופיל עדיין מופעל וההתקן עדיין מופיע, אבל הנתיב שהגיע איתו פעם אינו מגיע יותר.
גם ווי היד שכתבו ידנית זזים. סקריפט שהתקין נתיב ברגע צפוי ברצף הישן עשוי כעת לרוץ לפני שהממשק קיים, או אחרי שהלקוח כבר חרג מזמן.
השוו את הפרופיל החי לתוסף שבאמת יש לכם, ולא להתנהגות שאתם זוכרים. אם מפתח נעלם מהתיעוד, העבירו את העבודה לסקריפט מפזר או לתחליף נתמך במקום לשחזר את המאפיין הישן.
שלושה מצבים, שלושה תיקונים שונים
החליטו באיזה מצב אתם לפני שנוגעים במשהו, כי אתחול הורס את הראיות והתקלה חוזרת בשינוי הרשת הבא.
| What the lookup shows | What it means | Repair |
|---|---|---|
| A default route via a device that exists but is unused | Leftover route from an earlier activation | Remove the stale entry, or bounce the profile that installed it |
| A tunnel device with no client process | The client skipped its cleanup | Fix the disconnect path, then clear the leftover device state |
| No tunnel device and no active profile | Missing base connection or broken pairing | Bring up the base, then pair the VPN with it again |
סיימו בחיפוש אחד לכתובת ציבורית, אחד לכתובת פנימית ושאילתת שם אחת. אם הכתובות עובדות והשם לא, התקלה שנותרה היא היקף התחום בפותר, וטבלת הנתיבים מעולם לא הייתה הבעיה.