למה לכידת VPN מנותב לא מציגה לעולם את תג ה-VLAN של הסניף

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

הביטו במה שממשק המנהרה באמת נושא

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

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

ip -d link show tun0
tcpdump -i tun0 -nn -e -c 20

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

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

עמדו באחד משלושה מקומות וקבלו את מה שהוא יכול לראות

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

שלושת המיקומים האלה עונים על שלוש שאלות שונות, ולכידה אחת לא יכולה להיות כולן בעת ובעונה אחת.

tcpdump -i eth0 -nn -e 'vlan' -c 10
tcpdump -i tun0 -nn -c 10

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

החליפו את התג החסר במיפוי שתוכלו להגן עליו

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

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

ip route get 10.20.30.40
ip -br addr show

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

בדקו את נתיב החזרה ואת המטען לפני שתסמכו על התוצאה

נקודת בדיקה שרואה כיוון אחד בלבד תפספס חצי מהשיחה, וניתוב א-סימטרי נפוץ ברגע שיש VPN. אמתו שהתשובות עוברות באותו חיישן לפני שתראו בלכידה חד-צדדית לכידה שלמה.

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

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