גשר TAP ל-VLAN אחד: חברו את תת-הממשק

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

הרחבת VLAN אחת פירושה תחום layer-2 אחד, והגשר חייב להצטרף לאותו תחום ולא ל-trunk שנושא את כולם.

התג לא מופיע מפני שגישרתם את ה-trunk

קחו uplink של לינוקס eno1 הנושא VLAN 120 אל מתג מנוהל. העיצוב שעובד ל-VLAN יחיד הוא tap_vpn מגושר אל br_vpn, כאשר br_vpn מכיל את eno1.120 ולא את eno1. תת-הממשק של ה-VLAN מחיל את התג ביציאה ומסיר אותו בכניסה, כך שהגשר רואה רק פריימים ללא תג עבור אותו VLAN יחיד. שימו במקום זאת את הממשק הפיזי בגשר, ואותם פריימים ייצאו ללא תג ביציאת trunk, וזה לא מה שתכננתם.

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

שני עיצובים לגיטימיים, בעל תג אחד

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

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

העבירו את הכתובת יחד עם החברות

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

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

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

אמתו את החברות לפני שאתם מאשימים את הנתיבים

קראו את המצב הנוכחי ולא את המתוכנן: ip -d link show dev eno1.120 מדפיס את מזהה ה-VLAN ואת האב שלו, ip link show master br_vpn מפרט את חברי הגשר, ו-bridge vlan show מדווח על חברות לפי יציאה ועל הטיפול ביציאה. בעיצוב תת-הממשק, ודאו שהתקן ה-TAP והתקן ה-VLAN הם החברים. בגשר מודע ל-VLAN, בדקו את מדיניות היציאה עצמה, מפני שגשר קיים אינו מוכיח מה הוא מתיר.

לאחר מכן בדקו לקוח מורשה אחד מול שירות באותו VLAN, וזכרו ש-ARP, מדיניות חומת האש ונתיב התשובה הם עניינים נפרדים מהחברות. אם אתם לוכדים מנות, שימו לב שה-offload החומרתי יכול לשנות היכן תגי VLAN מופיעים במעקב. שמרו גם על היקף כן: לקוח TUN מנותב אינו הופך לחבר VLAN משום שינוי גשר, ותעבורת לקוח-ללקוח אינה מחליפה את חיבור המארח ל-VLAN.