מכונת GCP עם כמה NIC: מדוע התשובות יוצאות מהממשק הלא נכון

חיבור ממשק שני למכונת Compute Engine נותן לה חיבור רשת נוסף, לא נתיב חזרה סימטרי. האורח עדיין בוחר ממשק וכתובת מקור מהמסלולים והכללים שלו. לאחר מכן Google Cloud מחיל ניתוב VPC ומדיניות חומת אש סביב הממשק שממנו יצא החבילה. כששני ההחלטות האלה אינן מתיישבות, בקשות מגיעות ב-NIC אחד והתשובות יוצאות בשני, והסניף רואה שיחה חצי פתוחה.

עברו את הנתיב בחמישה שלבים והאי-התאמה תתגלה לפני שתכתבו כלל מדיניות.

שלב 1: מפו את ה-NIC בענן להתקנים באורח

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

תעדו כתובות, שמות התקנים וה-VPC שכל אחד שייך אליו. מפת שלוש העמודות הזו היא הקלט לכל שלב בהמשך.

שלב 2: תנו שם לשתי החלטות הניתוב

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

מסלול שנראה ב-VPC הפונה ל-VPN אינו הופך למסלול אורח שבוחר באותו NIC. מסלול הענן מתאר מה הרשת יכולה לספק, בעוד מסלול האורח קובע מה החבילה עושה.

שלב 3: בחרו מדיניות נתיב חזרה

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

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

שלב 4: בדקו את המסננים של האורח עצמו

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

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

שלב 5: בדקו זרימה אחת לכל נתיב

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

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

מה NIC שני לא נותן לכם

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

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