למה route -interface לא מגיע למארח מחוץ לקישור

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

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

הממשק הוא היציאה, הקפיצה הבאה היא המסירה

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

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

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

מה דגל הממשק באמת קובע

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

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

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

הנתיב שיעד מחוץ לקישור צריך

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

ב-macOS הבדיקה לקריאה בלבד היא route -n get 198.51.100.25. קראו את שורות השער והממשק יחד ובדקו שהשער הוא כתובת שה-Mac באמת מגיע אליה. שער בתת-רשת אחרת, או כזה שנעלם מאז שינוי הרשת האחרון, מייצר נתיב שנראה נכון ולא מעביר דבר.

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

קראו את הבחירה הנוכחית לפני החלפתה

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

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

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

מנהרות ומדיניות משנות את הצורה

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

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

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