בדיקת נתיב VPN ב-macOS: route get בלי לשנות דבר

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

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

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

הצורה היא route -n get ואחריה הכתובת: route -n get 203.0.113.10, כשכתובת התיעוד מייצגת את היעד שלכם. השתמשו ביעד המורשה ובמשפחת הכתובות המתאימה, כי תשובת IPv4 לא אומרת דבר על משאב שעובד רק ב-IPv6. התיעוד של כלי route מתאר את פעולת get ואת השדות שהיא מדפיסה.

קראו את הממשק ואת השער כראיות

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

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

נתיב נכון אינו בקשה שעובדת

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

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

הפרידו בין נקודת הקצה לבין המשאב

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

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

קודם לקרוא, אחר כך לשנות

השאירו את route add ואת route delete מחוץ למעבר הראשון. ב-Mac שאתם מנהלים מרחוק, עריכה רשלנית אחת של הטבלה עלולה לקחת בדיוק את הדרך חזרה למכונה, ואף אחד לא יוכל לסיים את האבחון. החליטו מהו הנתיב הנכון, כתבו כיצד לבטל את השינוי, ורק אז הריצו אותו. לבדיקה אין זנב כזה.

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