VPN מדווח מחובר אבל שום דבר לא מנותב: שני מקומות לבדוק

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

קודם כל שאלו את הליבה באיזה התקן היא תשתמש

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

המקרה השני הוא המקרה הרגיל לאחר שכבל מחליף את האלחוט, והוא מציג את עצמו כ-VPN שבור.

ip route show default
ip route get 203.0.113.9

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

אחר כך קראו את פותר השמות לכל קישור, לא לכל קובץ

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

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

resolvectl status
resolvectl query app.internal.example

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

איך מסלול מיושן שורד את השינוי

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

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

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

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

הבדילו בין מצב מיושן לבין אב חסר

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

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

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