TAP בלי גשר: מקטע וירטואלי עם קישור עולה מנותב

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

בנו את המקטע המבודד

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

ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr add 10.77.0.1/24 dev tap0

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

נתבו מעבר לגבול

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

כתבו את הנתיב ואת כלל חומת האש כשינוי אחד, כי כל אחד לבדו יוצר מצב שנראה מצד הלקוח כמו כשל ניתוב.

החליטו על נתיב החזרה

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

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

שמרו על היקף השידור במכוון

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

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

אמתו, ואז כתבו את החזרה לאחור

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

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