הוספת תת-רשת מקומית ל-AWS VPN: VGW מול Transit Gateway

VPN קיים מסוג Site-to-Site נושא את 10.60.0.0/16, רשת שירות חדשה מופיעה מאחורי אותו שער מקומי כ-10.70.0.0/16, ומישהו שואל אם נדרש פרוקסי. בדרך כלל לא: נתיב מנותב יכול לשאת את הקידומת, אבל רק אם שלושה דברים מסתדרים יחד, ואילו שלושה תלוי בארכיטקטורת AWS שכבר מופעלת אצלכם. לשער פרטי וירטואלי יש גבול אחד של טבלת ניתוב; transit gateway מוסיף גבול שני. הכרזה נכונה עם טבלה שגויה מייצרת הפעלה שנראית תקינה ולא מספקת דבר.

פרסמו קידומת שהשער באמת יכול לספק

השער המקומי זקוק לנתיב קדימה אל הרשת החדשה לפני שכל הכרזה מקבלת משמעות. הכרזה על 10.70.0.0/16 דרך BGP אומרת ל-AWS לאן לשלוח חבילות לטווח הזה; היא אינה יוצרת את נתיב ההעברה המקומי שהופך את הטווח לנגיש בקצה השני. ודאו שלשער יש נתיב לקידומת שמצביע על ההתקן שמחזיק בה, ושההתקן מוגדר להשיב עבור הכתובות הללו. מדיניות הייצוא ומגבלות הקידומות המתקבלות הן האילוץ הבא, כי קידומת שההפעלה מסננת לא מגיעה ל-AWS כלל.

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

נתיב ראשון: גבול השער הפרטי הוירטואלי

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

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

נתיב שני: transit gateway מוסיף טבלה

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

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

גם תפוצת נתיבים אינה מעניקה את הקידומת לכל צירוף. היא מפיצה אותה לטבלאות שמוגדרות לקבל אותה.

נתיב החזרה הוא החלטת מדיניות בפני עצמה

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

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

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

מתי הפרוקסי הוא באמת הגבול הטוב יותר

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

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