אתרים מגושרים עדיין זקוקים להחלטת יציאת אינטרנט מקומית

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

הגשר מעביר פריימים, לא החלטות

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

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

איך לקוח בוחר את השער שלו

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

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

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

תנו ל-DHCP לבטא את היציאה המיועדת

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

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

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

בדקו את ארבעת הדברים בנפרד

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

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

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