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

התחילו בשם, לא במנהרה

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

resolvectl query host.internal
getent hosts host.internal

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

שאלו את הליבה איזה מסלול בחרה

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

ip route get 10.20.30.40
ip -brief address show

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

בדקו את גודל החבילה

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

ping -M do -s 1400 10.20.30.40

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

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

בדקו את הצד הרחוק

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

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

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

מפו את התלונה לשלב אחד

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

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

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

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