מדוע חיישן ה-VPN שלך לא רואה לעולם את תג ה-VLAN של הסניף
מנהרה מנותבת משחזרת מנות, לא את המסגרות שנשאו אותן. ארבע בדיקות של סוג הממשק, מיקום החיישן, הקשר המקור ונתיב התשובה.
חיישן בצד ה-VPN רואה שתי VLAN של סניפים כתעבורת IP רגילה, והתג שזיהה כל סניף על החוט שלו עצמו נעלם. זה מה שעושה מנהרה מנותבת: היא משחזרת מנות, לא את מסגרות ה-Ethernet שמסרו אותן. אם התג החסר חשוב תלוי לחלוטין בשאלה שאתה שואל את החיישן. בצע את ארבע הבדיקות שלהלן לפי הסדר ותדע איזו נקודת תצפית יכולה לענות עליה.
ראשית: קבע מה המנהרה שלך משחזרת
ממשק TUN נושא מנות IP, ולכן כותרת ה-VLAN של מסגרת הסניף נעצרת בנתב שדחף את התעבורה למנהרה. ממשק TAP נושא מסגרות Ethernet, כלומר תגים יכולים לשרוד כאשר הגשר וכללי הקבלה של VLAN מאפשרים להם לעבור. קרא את סוג הממשק לפני שאתה מהרהר מה אמורה להכיל לכידה.
אף אחת משתי האפשרויות אינה פגם. שתי התכנונות עונות על שאלות שונות ומשאירות את התג במקומות שונים.
אמת את הממשק בעצמך במקום להסיק אותו משם המוצר. פרטי הקישור מציינים את סוג ההתקן ומציגים את הדגלים בתוקף, ולכידה שנלקחה בהתקן TUN לא תקבל כותרת Ethernet רק מפני שביקשת אחת. אם בכל זאת מופיעים תגים בלכידת TUN, אתה כמעט בוודאות קורא ממשק אחר או מנהרה שנושאת מסגרות בתוך המטען שלה. רשום באיזה מקרה אתה נמצא לפני שתמשיך.
שנית: הצב את החיישן במקום שבו האובייקט עדיין קיים
שלושה מיקומים מכסים את רוב התכנונות המנותבות: מקטע ה-Ethernet של הסניף, הרשת החיצונית בין קצוות המנהרה והנתיב לאחר עיבוד המנהרה. כל אחד רואה אובייקט אחר, והתג קיים רק בראשון. בחירת מיקום חיישן היא החלטה על האובייקט שהמדיניות צריכה, ולא עניין של נוחות.
| Observation point | What is actually there | Question it can answer |
|---|---|---|
| Branch Ethernet segment | Tagged frames on the local wire | Which VLAN carried this frame here |
| Outer tunnel network | The protected carrier between endpoints | Which endpoints are exchanging traffic |
| After tunnel processing | Recovered IP packets | Which branch prefix the packet claims |
נסח את שאלת המדיניות במונחים שהטבלה יכולה לענות עליהם, והיא בדרך כלל נפתרת מעצמה. אם הכלל צריך לדעת מאיזה סניף הגיעה מנה, מיפוי הקידומות במורד הזרם עשוי להספיק, אבל רק כל עוד המיפוי הזה מדויק וחד-משמעי. אם הכלל צריך לדעת לאיזה פורט הגיעה המסגרת, אתה צריך את המיקום הראשון, כי שום דבר במורד הזרם לא יכול לשחזר אותו. חיישנים שממוקמים מתוך הרגל ולא מתוך שאלה הם הדרך שבה צוותים מגיעים בסופו של דבר לדרוש שדה שהתכנון מעולם לא נשא.
מנהרה שנושאת Ethernet היא תכנון אחר וזקוקה לבדיקה משל עצמה של מה שהקצוות משמרים או כותבים מחדש. בחירה ב-TAP לבדה עדיין אינה מגדירה את הגשר, את כללי הקבלה של VLAN או את מדיניות הבדיקה.
שלישית: הרווח את הקשר המקור במקום לסמוך עליו
טווח כתובות אחד לכל סניף הוא התחליף המקובל לזהות VLAN, והוא מחזיק רק כל עוד המיפוי נשאר אחד לאחד. קידומות חופפות, תרגום ושער משותף כל אחד שובר את ההנחה הזו באופן שנראה כמו בעיית איכות נתונים ולא בעיית תכנון. כתוב את המיפוי עם הגבולות שלו ואמור מה קורה למנה שמתאימה לשתי שורות. קידומת שמופיעה בשני סניפים צריכה להיות שגיאה שאתה מגלה, לא הטלת מטבע שאתה מקבל.
הקשר שמספק הלקוח אינו ראיה לחברות. זו טענה, ומקומה בעמודה אחרת.
היכן שההבחנה חשובה, השתמש בנתוני שיוך שאתה שולט בהם: איזו מופע מנהרה קיבל את החיבור, באיזה ממשק הגיעו המנות, מה אומרת טבלת הניתוב המקומית על אותו עמית. תווית שמספק הלקוח היא רמז שימושי וקלט הרשאה חסר תועלת. אם החיישן אינו יכול לבסס את השיוך מצדו שלו, המדיניות זקוקה לכלל רחב יותר ולא להשערה בטוחה.
רביעית: אמת את נתיב התשובה ומה פענוח ההצפנה מפספס
חיישן שרואה כיוון אחד בלבד עדיין יכול להיראות תקין, כי בקשות ממשיכות להגיע בזמן. בדוק את נתיב התשובה במפורש, ובדוק אותו עבור אותו זרם ולא עבור נגישות כללית. נראות חצי-דופלקסית הופכת לפער שקט בכל מסקנה מבוססת מצב שאתה מסיק ממנה.
שחזור תעבורת IP פנימית גם אינו אותו דבר כמו לראות את היישום שבתוכה, כי TLS שנישא על המנהרה נשאר TLS.
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5שתי הפקודות האלה עונות על שאלת הממשק ומראות מה הלכידה באמת מכילה, וזה מהיר יותר מאשר להתווכח על הארכיטקטורה. החלף את שם הממשק שהתכנון שלך משתמש בו והרץ את הלכידה בזמן שהזרם שמעניין אותך פעיל. כאשר לא מופיע תג בהתקן TUN, הממצא הוא שהתכנון בחר ניתוב ולא גישור, ולא שהחיישן איבד נתונים. לאחר מכן או העבר את החיישן למיקום שיכול לראות את התג, או כתוב מחדש את הכלל במונחים שהמיקום הנוכחי יכול לתמוך בהם.