למה שני אתרים עם אותה תת-רשת אינם LAN אחד

שני משרדים משתמשים שניהם ב-192.168.77.0/24, ומישהו מציע מנהרה כדי שהם יהיו רשת אחת. המשפט נשמע פשוט ומסתיר שלוש תכנונים שונים: שתי רשתות LAN עצמאיות שמתנגשות, מקטע Ethernet אחד שנמתח בכוונה על פני WAN, וסידור proxy-ARP שעונה עבור כתובות מרוחקות. איזה מהם יש לכם קובע מה המארח עושה עם החבילה, והתשובה נראית לפני שהשער VPN מעורב.

המארח מחליט לפני הנתב

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

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

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

ARP הוא שאלה של קישור מקומי

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

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

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

מקטע מתוח נושא מסגרות, לא מסלולים

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

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

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

Proxy ARP הוא תכנון שלישי

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

זה כלי צר יותר מגישור: הוא תלוי בהעברה, במסלולי חזרה ובבעלים ברור לכל כתובת.

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

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

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

אשרו איזה תכנון באמת יש לכם בכך שתשאלו מארח מה הוא עושה עם היעד:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

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