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

התסמין והמסקנה השגויה

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

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

צלמו את מחסנית לינוקס בארבע פקודות

התחילו במצב קריאה בלבד ותעדו את המצב לפני שמשנים משהו: ip -br link לנוכחות ממשקים, ip -br address לכתובות, ip route למסלולי IPv4 ו-ip -6 route במקום שבו IPv6 חשוב. תיעוד כלי ip מבדיל בין העצמים האלה, והופעה של ממשק ברשימה אינה הוכחה שיש לו כתובת עובדת או מסלול שמיש.

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

האם זה קישור, כתובת, מסלול או שם?

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

כל מקרה מצביע על עבודה אחרת: מנהל התקן או קושחה להתקן חסר, כבילה או מתג כשאין נשא, DHCP או תצורה סטטית לכתובת חסרה, וניתוב או מדיניות למסלול חסר. בעיית פותר מצביעה על systemd-resolved, NetworkManager או תצורת DNS מקומית.

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

ואז השוו את מעבר האתחול

Windows Fast Startup הוא כיבוי היברידי ששומר על מצב הפעלת הגרעין במקום לבצע אתחול מלא. התיעוד של Microsoft על מצבי צריכת חשמל מבדיל בינו לבין הפעלה מחדש וכיבוי מלא, ולכן אותה חומרה יכולה להתנהג אחרת בשני המעברים.

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

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

מה לא לשנות

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

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

מאמרים קשורים