VPN מסוג L2 מול מנהרת L3: חמישה בדיקות לפני גישור אתר

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

בדקו מה היישום באמת מכניס לתיל

לפני ששם מוצר כלשהו נכנס לדיון, תפסו דקה מהתעבורה שצריכה לחצות את הקישור: tcpdump -i eth0 -nn -e 'not ip'. האפשרות -e מדפיסה את כותרת שכבת הקישור, וזה בדיוק החלק שמנהרת ניתוב משליכה. אם הלכידה נשארת ריקה, היישום שלכם מדבר IP ומנהרת L3 מעבירה אותו ללא שינוי. אם בכל זאת מופיעים פריימים, רשמו את ה-EtherType, כי 0x0806 הוא ARP, 0x88cc הוא LLDP, וערך של יצרן בדרך כלל אומר פרוטוקול גילוי בלי חלופת IP. זו הנקודה שבה ממשק tun רגיל כבר לא מספיק.

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

בדקו אם הגילוי חייב לחצות את הקישור

למנהרת ניתוב אין מקטע משותף, ולכן שום דבר שממוען לקבוצה לא מגיע לקצה השני. ARP, שידורי DHCP, mDNS בכתובת 224.0.0.251, SSDP ושאילתות שמות NetBIOS מניחים כולם קישור שמספר מארחים שומעים בו-זמנית.

שאלו באילו מהם היישום באמת תלוי, והאם כבר קיים עבורו פרוקסי. ממסר DHCP, החזרת mDNS ורשומות ARP סטטיות כל אחד מסיר תלות אחת, וכל אחד הוא שירות נוסף להריץ ולנטר. כשנשארים שניים או שלושה, גישור הוא התשובה הכנה.

בדקו כמה עולה לכם הכותרת הנוספת

פריימים צריכים מקום לחיות בו, ולכן כל מה שאתם שולחים מקבל מחסנית כותרות שנייה סביבו. בשכבת-על VXLAN זה אומר כותרת IP חיצונית, כותרת UDP וכותרת VXLAN בגודל 8 בייט, מה שדוחף מטען מלא של 1,500 בייט מעבר ל-MTU הנתיב של קישור אינטרנט רגיל של 1,500 בייט. OpenVPN במצב tap מוסיף תקורה משלו באותו כיוון. בלי MTU נמוך יותר בצד הפנימי תקבלו קישור שעונה ל-ping ונתקע בהעברה הגדולה הראשונה.

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

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

בדקו איזה סוג של VPN מסוג L2 מציעים לכם

המונח עצמו מעורפל, והעמימות היא שקובעת מי נושא את התעבורה שלכם. לפעמים הוא מתאר את המטען: פריימי Ethernet בתוך IP, שנשלחים דרך האינטרנט כמו כל מנהרה אחרת, כפי שעושים VXLAN, ZeroTier ומצב tap של OpenVPN. לפעמים הוא מתאר שירות קנוי: מעגל Ethernet של ספק או מוליך מדומה MPLS שמחבר שני אתרים בתוך רשת אחת של ספק.

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

בדקו את הפתרון הזול יותר לפני שתגשרו

רוב הבקשות לקישור מגושר מגיעות מכשל אחד של פתרון שמות, לא מפרוטוקול שבאמת צריך פריימים. העבירו קודם את הפותר ואת תחום החיפוש דרך המנהרה המנותבת: dhcp-option DNS 10.8.0.1 יחד עם dhcp-option DOMAIN internal.example בתצורת שרת OpenVPN פותר מספר מפתיע מהם. מעביר מקומי בצד המרוחק עושה את אותה עבודה בלי להזיז שום תעבורת שידור.

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

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