גשר TAP מבודד בין שני לוחות דרך OpenVPN

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

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

מה הגשר באמת מעביר

גשר הוא מתג המיושם בתוכנה. הוא לומד איזו כתובת MAC מופיעה מאחורי איזו יציאת חבר ומעביר מסגרות בין חברים בלי להתייעץ בטבלת ניתוב IP. שום דבר בתיאור הזה אינו כולל תת-רשת, שער או מסלול ברירת מחדל, ולכן הפעלת העברת IP אינה יוצרת את החיבור הזה ולכן ping יכול להצליח בעוד תעבורה אחרת עדיין נכשלת. לוח יכול להגיע לעמית שלו בלי שום מסלול ברירת מחדל מוגדר כלל, מה שמפתיע אנשים שמצפים ששכבה שתיים תתנהג כמו שכבה שלוש.

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

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

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

כתבו את הכתובת על הגשר, לא על יציאות החבר שלו

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

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

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

למה יציאה ייעודית אחת לכל ספסל

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

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

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

הגבול שהגשר אינו יוצר

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

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

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

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

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

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

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

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