VLAN של לקוחות או trunk מתויג: בחירת מצב OpenVPN הנכון

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

מה המצב המודע ל-VLAN באמת בונה

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

צד ה-TAP של השרת מקבל מדיניות קבלה משלו, מתויגת או לא מתויגת, דרך vlan-accept. העברה בתוך אותו מתג מתרחשת רק בין VID תואמים, כולל כאשר client-to-client מוגדר, כך ששני לקוחות ב-VLAN שונים לא יכולים להגיע זה לזה דרך השרת למרות ששניהם מחוברים אליו.

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

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

מה trunk שקוף דורש במקום

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

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

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

שלושה תנאים שמכריעים את התשובה

ראשית, האם פלטפורמת הלקוח תומכת ב-TAP בכלל? אנדרואיד ו-iOS לא תומכות, והתמיכה ב-macOS מוגבלת, ולכן צי של משתמשים ניידים פוסל כל תכנון TAP, לא משנה איך מסודרים ה-VLAN. הפעלה של TUN מנותב נושאת מנות IP ולא פריימי Ethernet, וכל תצורת VLAN בצד השרת לא משנה זאת. בדקו את הצי לפני תכנון הטופולוגיה, כי התנאי הזה הוא זה שאי אפשר לעקוף. זה גם התנאי שמתגלה לרוב אחרי סיום העבודה על המתג.

שנית, מי מקצה את ה-VLAN? אם התשובה היא «השרת, לפי מי שאומת», מודל המתג מתאים. אם התשובה היא «תשתית המתגים הקיימת, עם תגים שכבר קיימים», דרוש תכנון ה-trunk.

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

בדיקת הבחירה שעשיתם

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

ip -d link show tap0
bridge vlan show

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

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