הגדרת ממשקי גשר עבור וירטואליזציה KVM ו-LXC

הגדרת bridge Linux: היכן נקרעת רשת המכונות הווירטואליות

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

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

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

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

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

מה נותן גשר מנוהל בסביבת הווירטואליזציה

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

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

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

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

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

מצבי רשת למכונות וירטואליות: macvtap, NAT וגשרים

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

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

שלבי העבודה: מביקורת טופולוגיה ועד מסירת הסביבה

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

1. ביקורת רשת ומלאי ממשקים. אוספים תמונה אמיתית: פורטים פיזיים, ערוצים מאוגדים, תיוג VLAN, גשרים קיימים וכתובות עליהם. בנפרד מחפשים אורחים שמחוברים ישירות לממשק המארח מחוץ לגשר — דווקא הם מתנתקים ראשונים בכל ארגון מחדש.
2. סכמת חיבור. לפני התיקונים מתאמים טופולוגיה: אילו גשרים יוצרים, מה מכניסים אליהם, היכן השער, כיצד הכתובות מתחלקות בין המארח למכונות, אילו רשתות מפרידים לפי VLAN ואילו פורטים נשארים לשירות.
3. הגדרת ממשקים. את הפרמטרים מעבירים לקבצי קונפיגורציה קבועים, ולא משאירים כפקודות בסשן — אחרת הרשת לא תשרוד הפעלה מחדש. את הגשר מגדירים עם תמיכה בתעבורה מתויגת במקום שצריך, ובלי תוספות מיותרות שאינן בשימוש בטופולוגיה.
4. בידוד תעבורה. מפרידים אורחים בעלי ייעודים שונים ברמת הגשר, כך שמכונה אחת לא רואה מקטע של אחרת. בודקים שהמדיניות לא חוסמת תעבורת שירות עם מערכת הניהול.
5. בדיקת קישוריות. מריצים בדיקות כתובות, שער, יעדים חיצוניים, תעבורה בין אורחים על אותו מארח ובין מארחים. בנפרד בודקים התנהגות לאחר הפעלה מחדש ולאחר ניתוק ערוץ אחד מהאיגוד.
6. מסירת הסביבה. מוסרים סכמה, קונפיגורציות תחת בקרת גרסאות עם הערות, סדר חזרה לאחור לטופולוגיה הקודמת ורשימת נקודות שבהן השינוי ישפיע על שירותים אחרים.

מה נשאר ללקוח: קונפיגורציות, סכמות, נהלים

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

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

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

מקרה בוחן: העברת סביבת וירטואליזציה לגשר ללא השבתה

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

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

מה עשינו

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

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

תוצאה במספרים

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

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

במה bridge שונה מ-NAT ומ-macvtap בפועל

תשובה קצרה: bridge נותן למכונה הווירטואלית כתובת משל עצמה באותו מקטע כמו המארח, NAT משאיר אותה מאחורי תרגום כתובות, ו-macvtap נותן כתובת ישירה אך מנתק את התעבורה בין המארח לאורח.

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

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

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

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

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

ספקות טכניים לפני הטמעת גשרים

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

מה תהיה ההשבתה בעת המיתוג?

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

כיצד מתבצעת חזרה לאחור מקונפיגורציה כושלת?

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

כיצד להפריד תעבורה לפי מקטעים?

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

האם אפשר לכלול בגשר כמה ממשקים פיזיים?

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

נדון בטופולוגיה שלכם ונחזור עם תוכנית עבודה

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

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

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