169.254 דרך VPN: הכתובת מעולם לא הייתה ניתנת לניתוב
יעד link-local נזרק לפני שהוא מגיע למנהרה, ולכן הוספת מסלולים רק מרחיבה את הכשל. בחרו בין תיקון תת-הרשת לבין גשר.
אתם מוסיפים את המסלול, המנהרה עולה, ובכל זאת ה-ping לצד השני מת באובדן מלא ולא ב«network unreachable». ההבדל הזה חשוב, כי הוא מסיט את המבט מטבלת הניתוב אל הכתובת עצמה. יעד 169.254 הוא link-local, והתחום שלו נגמר בהופ הראשון לפי התכנון, לא בגלל תצורה שגויה.
ההחלטה שנובעת מכך צרה וכדאי לקבל אותה במפורש: לתקן את תת-הרשת בצד השרת, או להרחיב את מקטע שכבה 2 כדי שהכתובת תחזור להיות משמעותית מקומית. כל השאר, כולל הוספת מסלול רחב יותר, רק מפיץ את אותו כשל ליותר יעדים.
הכתובת אינה חסרת מסלול, היא אינה ניתנת לניתוב
כתובות IPv4 מסוג link-local מקצות את עצמן כאשר שום דבר טוב יותר לא עונה; משם מגיע המיעון הפרטי האוטומטי ב-Windows והמקבילה במערכות אחרות. הטווח בשימוש בכל קישור בו-זמנית, וזו בדיוק הסיבה שזה עובד: שני מארחים באותו מקטע יכולים לדבר בלי שום תיאום.
בגלל אותה תכונה בדיוק אסור לנתב להעביר חבילות כאלה בין רשתות. קבלת חבילה המיועדת ליעד link-local והוצאתה דרך ממשק אחר תיצור עמימות, כי ה«מקומי» של השולח וה«מקומי» של המקבל הם מקומות שונים. אין חיפוש שיכול להכריע לאיזה מהשניים התכוון השולח. העברה כאן אינה בחירת מדיניות שמנהל יכול להפעיל; מחלקת הכתובות שוללת אותה.
לכן שער שמתקין את 169.254.1.10 כנגיש דרך המנהרה מבקש מהליבה דבר שהפורמט של הכתובת אוסר. החבילה נזרקת הרבה לפני שהיא מגיעה למארח המרוחק, ושום דיוק מסלול לא משנה את התוצאה.
למה מנהרה חושפת את בעיית התחום
ממשק TUN מעביר חבילות IP בין שני עמיתים ואין מאחוריו מקטע משותף. אין שידור, אין ARP לצד השני, ואין גילוי שכנים שיפתור יעד link-local לכתובת שכבת קישור.
התסמינים מתאימים בדיוק כשמכירים את מה לחפש. המסלול קיים בטבלה, ping מדווח אובדן מלא במקום רשת בלתי נגישה, וטבלת השכנים מציגה רשומה חסרה או כושלת. לכידה במנהרה מראה את החבילה יוצאת, וזה מפנה אנשים לקצה המרוחק במקום למחלקת הכתובות.
ב-Windows יש תסמין שני, לכאורה לא קשור, עם אותו שורש: מתאם שנשאר עם כתובת link-local בלבד אינו מקבל שער שמיש, ולכן זיהוי הרשת אינו יכול לסווג את החיבור ופרופיל חומת האש נופל ל-public. המנהרה אינה הסיבה; הכתובת היא.
החליטו בשלוש שאלות
הבחירה בין תיקון תת-הרשת לגשר על הקישור תלויה בשלושה תנאים, וכל אחד מהם יכול להכריע לפני שתפתחו קובץ תצורה.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
רוב המקרים עוצרים בשאלה הראשונה. מארח שמציג כתובת link-local בדרך כלל אומר ש-DHCP לא ענה, שכבל או VLAN שגויים, או שמישהו הקליד את הכתובת ביד. תיקון זה זול מכל עבודת מנהרה ומסיר את הבעיה מכל לקוח עתידי, לא רק מזה.
בדקו את צד השרת לפני שאתם מניחים משהו. הריצו ip addr show ו-ip route במארח, ו-arp -n או route print -4 בלקוח, כדי לראות אם הקידומת קיימת או שרק רשומה ישנה טוענת לכך.
מה עולה גשר כשהוא התשובה הנכונה
גישור מתאם פיזי עם מתאם TAP הופך את הלקוח המרוחק לחלק מתחום השידור המקומי. אז שידור וגילוי שכנים עובדים, וכתובת link-local חוזרת להיות משמעותית כי הלקוח באמת מקומי לאותו קישור.
העלויות אמיתיות ויש לומר אותן לפני שמישהו מסכים. תעבורת שידור חוצה את המנהרה, הלקוח חשוף למקטע המקומי לכל מטרה ולא רק לשירותים שהוא צריך, והשרת צריך כעת להעביר מסגרות במקום לנתב חבילות. זהו חילוף סביר לשולחן מעבדה או להתקן בלי נתיב תצורה ניתן לניתוב, וברירת מחדל גרועה לגישה מרחוק.
כשאתם מגשרים, דרושים שני החצאים: הגשר בשרת, ומסלול בפרופיל הלקוח שאומר אילו יעדים נמצאים בצד השני. גשר לבדו משאיר את הלקוח מנחש, ומסלול לבדו אינו מתקן מחלקת כתובות.