האם שני אתרים זקוקים לאותם VLAN ID עבור VPN אתר?
מזהי VLAN זהים אינם מתקנים VPN אתר מנותב: המנהרה מעבירה קידומות IP, ולכן תוכנית הכתובות והבוררים קובעים את הנגישות, ולא תגיות המתג.
אותם מספרי VLAN בשני משרדים נראים כאילו הם אמורים לעזור למנהרה בין אתרים, והם לא משנים דבר ממה שהמנהרה מעבירה. מזהה VLAN מסמן תחום שידור Ethernet בתוך בניין אחד; המנהרה מעבירה חבילות IP בין השערים. שני אתרים יכולים להשתמש במספור VLAN שונה לחלוטין ועדיין לנתב זה לזה, ושני אתרים יכולים להשתמש באותו מספור VLAN ועדיין לא להצליח להגיע זה לזה. המשתנה שקובע את הנגישות הוא תוכנית הכתובות.
המיתוס: אותם מזהי VLAN בשני הקצוות
האמונה מגיעה ממקום הגיוני. בתוך בניין אחד, שתי יציאות באותו VLAN יכולות לדבר ושתי יציאות ב-VLAN שונים לא יכולות, ולכן מספר ה-VLAN נראה כמו הדבר שמעניק קישוריות. לאורך מנהרה מנותבת אין מקטע Ethernet משותף שהתגית תוכל לתאר, והשערים אף פעם לא מחליפים תגיות VLAN.
מה שהמנהרה צריכה הוא זוג טווחי כתובות שאינם חופפים ומדיניות שמתירה את התעבורה ביניהם. שנה את ה-VLAN בכל משרד והמנהרה ממשיכה לעבוד, כי שום דבר בקונפיגורציית המנהרה לא התייחס אליו. זה המבחן שמכריע את הוויכוח: מחדש את המספור של VLAN, השאר את הכתובות כפי שהן וצפה אם המנהרה נשארת פעילה.
המבחן ההפוך מאלף באותה מידה. תן לשני המשרדים את אותה תת-רשת ושום כמות של מספרי VLAN זהים לא תהפוך כתובת לחד-משמעית.
מה המנהרה באמת מעבירה
IPsec מגן על חבילות IP לפי מדיניות שמבוטאת בכתובות, פרוטוקולים ויציאות. ארכיטקטורת IPsec מתארת את הבוררים האלה בשכבת IP, שנמצאת כמה שכבות מעל כל מה שתגית מתג מתארת. כשחבילה נכנסת למנהרה היא כבר עזבה את ה-VLAN; התגית נצרכה על ידי המתג המקומי.
עיצובים מבוססי מדיניות ומבוססי נתיבים נבדלים באופן שבו הם בוחרים את המנהרה, לא במה שהם יכולים להעביר. עמית מבוסס מדיניות מתאים בוררי תעבורה ושולח חבילות מתאימות לתוך המנהרה. עמית מבוסס נתיבים מנתב תעבורה בממשק מנהרה ומשאיר את ההחלטה לטבלת הניתוב. שניהם עדיין מנהלים משא ומתן על היקף הגנה, ולכן נתיב שמצביע על המנהרה אינו מרחיב את מה שהעמיתים הסכימו להגן עליו.
ההבחנה הזו מסבירה כישלון-למחצה נפוץ: הנתיב קיים, החבילות נכנסות למנהרה, והצד המרוחק מפיל אותן כי הבוררים שנוהלו במשא ומתן מעולם לא כללו את הקידומת הזו. קריאת המדיניות המותקנות מראה איזה היקף באמת נכנס לתוקף.
ip xfrm policy
ip route show
swanctl --list-sasהחפיפה שבאמת שוברת
שני משרדים עם תת-רשתות שונות מנותבים נקי דרך מנהרה, ומספרי ה-VLAN שלהם לא רלוונטיים. שני משרדים עם אותה תת-רשת לא, כי לבקשה עבור כתובת נתונה יש שתי משמעויות אפשריות וטבלת הניתוב יכולה לבחור רק אחת. מספור מחדש של אתר אחד הוא התיקון הנקי, והוא בדרך כלל זול יותר מהחלופות כשמביאים בחשבון את שינויי ה-DNS וחומת האש.
| Office | Local VLAN | Subnet | Result |
|---|---|---|---|
| A | 40 | 10.31.0.0/24 | Routes normally |
| B | 55 | 10.62.0.0/24 | Routes normally |
| B after renumber | 40 | 10.31.0.0/24 | Ambiguous, tunnel cannot help |
כאשר מספור מחדש בלתי אפשרי, עיצוב תרגום מכוון יכול להציג לכל צד תצוגות כתובות נפרדות. זה אומר מיפוי אחד לאחד, בוררים תואמים, רשומות DNS שמשקפות את התצוגה המתורגמת וניתוב חזרה ששורד את השכתוב. זהו עיצוב נתמך עם עלות תפעולית אמיתית, וזה לא מה ששינוי של VLAN ID עושה.
אותם מספרי VLAN בשני הקצוות הם לפעמים מקריות של תבנית משותפת, והתייחסות למקריות הזו כאל הסיבה למנהרה עובדת מובילה לשינוי הלא נכון כשמשהו נשבר מאוחר יותר.
משימה אחת לכל שכבה, בכתב
המתג המקומי מחליט אילו יציאות חולקות תחום שידור, ומספור ה-VLAN שלו הוא הנהלת חשבונות מקומית שאף אתר אחר לא צריך לדעת. השער מאמת את העמית ואוכף את היקף ההגנה שנוהל. טבלת הניתוב מחליטה לאן הולכת חבילה מפוענחת לאחר מכן, ומדיניות הגישה מחליטה אם בכלל היה צריך לאפשר את החבילה הזו.
הפרדה בין המשימות האלה היא מה שעושה שינויים לבטוחים. מספור מחדש של VLAN במשרד אחד נוגע במתג המקומי, בטווח ה-DHCP ואולי באזור חומת אש, והוא לא נוגע במנהרה. שינוי קידומת נוגע בבוררי המנהרה, בנתיבים בשני הצדדים ובמדיניות הגישה, והוא לא נוגע בתגיות המתג.
נתיבי חזרה, DNS פרטי ודרישות זהות אפליקציה הם שוב משימות נפרדות, ואף אחת מהן לא מגיעה בהעתקת מספר VLAN מהאתר האחר. מסמך עיצוב שמפרט קידומות נגישות ושירותים מותרים שורד החלפת מתג; מסמך שמפרט מספרי VLAN לא.
אמת את התמונה המקומית בכלי ה-bridge לפני שאתה מניח שתגית מגיעה למנהרה.
bridge vlan show
ip -br addr
ip route get 10.62.0.20כאשר הרחבת layer-2 היא הדרישה האמיתית
עיצובים מסוימים באמת זקוקים להתנהגות Ethernet בין אתרים: אפליקציה ותיקה שמסתמכת על גילוי בשידור, העברה שצריכה לשמור כתובת בזמן שמכונה עוברת, או פרוטוקול שמטמיע הנחות layer-2. מקרים כאלה דורשים שכבת-על או שירות גישור שנושא את המסגרות, ואז חברות ב-VLAN, מניעת לולאות וטיפול בכשלים הופכים לעניינים מקצה לקצה.
זהו תחום כשל גדול הרבה יותר, וזה צריך להיות בחירה מכוונת ולא התוצאה המקרית של ניסיון להפעיל שיתוף קבצים. שרת קבצים, מסד נתונים או אפליקציית ווב רגילים זקוקים לנתיב IP מורשה, והם יהיו שמחים יותר בלי תחום שידור מתוח מתחתיהם.
כתוב את חוזה ה-VPN כקידומות נגישות בתוספת שירותים מותרים, ורשום את תגית ה-VLAN רק במקום שבו הפעילות המקומית זקוקה לה. אז כל משרד יוכל למספר מחדש את המיתוג שלו בלי להפוך כל שינוי לעיצוב מחדש של המנהרה.