VPN אורח ב-ESXi: ניתוב או גישור — החליטו לפני קבוצת הפורטים
TUN מנותב זקוק למסלולי חזרה; TAP מגושר זקוק לנגישות שכבה 2 ולמדיניות קבוצת פורטים רחבה יותר. קבעו את התפקיד לפני הרחבת מצב promiscuous.
נתבו את החבילות או הרחיבו את תחום ה-Ethernet: שינוי קבוצת הפורטים בא אחרי הבחירה הזו. מנקודת מבט של יישום עם כתובת פרטית התוצאות עשויות להיראות זהות, בעוד דרישות ההיפרוויזור שונות לחלוטין. לכן קבוצת הפורטים מורחבת ראשונה והשאלה התכנונית נענית שנייה, בדרך כלל אחרי סופת broadcast. עברו על הבדיקות האלה לפי הסדר ועצרו כל עוד הדרישה מעורפלת, כי שום הגדרה של קבוצת פורטים לא מתקנת תכנון שמעולם לא נבחר.
ההחלטה שייכת לבעל השירות; תצורת ההיפרוויזור צריכה ליישם אותה, לא לקבוע אותה בטעות.
בדקו מה באמת דרוש לקצה המרוחק
רשמו את השירותים שהלקוחות המרוחקים חייבים להגיע אליהם ואת הפרוטוקולים שהם משתמשים בהם. אם הרשימה היא קומץ שירותי TCP על קידומות מוכרות, ניתוב מכסה אותה. אם משהו באמת דורש שכנות שכבה 2 — גילוי תלוי broadcast, פרוטוקולים שאינם IP, התקן שלא מקבל שער — ניתוב לא יכול לחקות זאת ויש לומר זאת מוקדם. היו כנים לגבי הערכים שאינם IP ברשימה הזו, כי שם תכנון מנותב נכשל בשקט שבוע לאחר מכן.
לאחר מכן בדקו את מאגר הלקוחות. תכנון מנותב דורש טווח כתובות ומסלול חזרה מפורש בצד המרוחק; תכנון מגושר דורש שתחום ה-Ethernet המורחב יהיה בעל הקצאת כתובות ובידוד. מה שתבחרו, מישהו מחוץ ל-VM הזה חייב להסכים לכך.
מה כל תכנון דורש מהרשת הווירטואלית
שני התכנונים נבדלים במה שהרשת הווירטואלית חייבת לסבול, והטבלה היא הדרך הקצרה לראות זאת:
| תכנון | תפקיד בצד האורח | מה הרשת הווירטואלית חייבת להכיל | מצב כשל אם בוחרים לא נכון |
|---|---|---|---|
| TUN מנותב | נתב בין קידומות נפרדות | מאגר לקוחות מנותב ומסלולי חזרה בצד המרוחק | הלקוחות מגיעים לשער ולעולם לא מגיעים לשירות שמאחוריו |
| TAP מגושר | גשר שכבה 2 ללקוחות שמצטרפים | זהויות Ethernet נוספות, תעבורת broadcast וכללי VLAN | ה-vSwitch מפיל פריימים, או שהתכנון דורש מצב promiscuous שאיש לא אישר |
ניתוב משאיר את תחום ה-broadcast במקומו ונותן מקום טבעי להגביל אילו שירותים חוצים את השער. גישור מזיז את הגבול: הלקוחות הופכים למשתתפים בתחום ה-Ethernet המורחב, והקצאת כתובות, בידוד וכל מדיניות שכבה 2 חלים עליהם כעת. כתבו את השורה שנבחרה ביומן השינויים. משפט כמו «TUN מנותב, מאגר לקוחות 10.90.0.0/24, מסלול חזרה בליבה» מונע מהמהנדס הבא לדון מחדש בתכנון מתוך הגדרות קבוצת הפורטים.
מי צריך להיות רשאי לראות את הפריימים של מי
שאלו את בעל הפלטפורמה שאלה אחת לפני שנוגעים בקבוצת הפורטים: האם התכנון דורש שה-VM הזה יקבל פריימים המיועדים למשתתפים אחרים? אם התשובה שלילית, דבר בסעיף הזה אינו חל, כי TUN מנותב לעולם אינו זקוק לנראות הזו. אם התשובה חיובית, ההנחיה של Broadcom לגבי מצב promiscuous היא הקריאה שחשובה: היא מפרטת כמה יותר מה-vSwitch ה-VM יכול לראות וממליצה להגביל את המדיניות הזו לקבוצת פורטים אחת.
התייחסו לזה כבדיקת דרישה, לא כהיתר. הפעילו את ההגדרה עבור חיבור ייעודי אחד כשצורך הגישור כתוב, והשאירו אותה כבויה בכל מקום אחר. trunk VLAN רחב שהועתק מדוגמת גשר אחרת הוא החלק שאיש לא זוכר להסיר, ותכנון של VLAN יחיד צריך להישאר VLAN יחיד.
תעדו איזו קבוצת פורטים השתנתה ולמה, באותו מקום שבו רשמתם את שורת התכנון. הצימוד הזה הוא מה שמאפשר את הביקורת הבאה.
שמרו על אובייקטי האורח מפורשים
בתוך Linux, חברות בגשר ובעלות על כתובת הם אובייקטים נפרדים, וערבוב שלהם יוצר את המצב המבלבל של חצי-עבודה. הקצו כתובות לממשק הגשר או למנהרה המנותבת, לא לשני צדי אותו מסלול, והשאירו את פורטי החברים ללא תצורת IP.
הימנעו מלהניח תת-רשת אחת באופן עצמאי על TUN מנותב ועל ממשק Ethernet לא קשור. תצורה כזו יוצרת שני מסלולים לאותה קידומת, תגובות א-סימטריות ושרשור תמיכה על flapping שאינו מזכיר אף אחד מהמסלולים. אם האורח מארח גם מכולות או היפרוויזור מקומי, בדקו שהם לא מגשרים כבר לאותו uplink. שני גשרים על NIC אחד הם תכנון, לא תאונה שתרצו לגלות בחלון שינוי.
אשרו באמצעות מסלול חבילה, לא באמצעות ping
אמתו את המסלול בפועל, לא רק את הנגישות. מלקוח, אשרו איזו כתובת מקור מגיעה לשירות המרוחק, ואז שהתגובה חוזרת באותה דרך. באורח, בדקו את מוני ההעברה עבור הזרימה הספציפית, ובקבוצת הפורטים אשרו שלא הופעלה נראות נוספת מעבר למה שהתכנון הנבחר דורש.
לבסוף, בדקו את כיוון הכשל. עצרו את המנהרה או נתקו את הלקוח ובדקו שהתעבורה לא נופלת בשקט למסלול מנותב שחשבתם שאינו בשימוש, כי הנפילה הזו היא הדרך שבה תכנון מגושר הופך בשקט לנתב לא מכוון.