VPN אחד מאתר לאתר עבור כמה VPC ב-AWS Transit Gateway

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

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

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

למה peering אינו הקיצור שמקווים לו

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

המגבלה הזו היא תכונה של peering, לא מכסה שאפשר להעלות.

שיוך והפצה עושים עבודה שונה

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

מרכז קטן ומחובר במלואו הוא המקרה הקל.

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

מסלולי עומסי העבודה גרים במקום אחר

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

בחרו ניתוב דינמי או סטטי במכוון; peering אינו מספק אף אחד מהם.

לבודד שלוחות בלי לאבד גישה מקומית

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

זו בידוד ניתוב, וזו אינה הרשאה של היישום.

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

מה המרכז לא מתקן

תוכניות הכתובות חייבות להישאר ללא חפיפה, כי המרכז אינו מאפשר לקידומת אחת לזהות שני עומסי עבודה. כל חיבור VPC זקוק לכיסוי Availability Zone שעומסי העבודה שלו מצפים לו. עם BGP, המסלולים של מכשיר הלקוח חזרה לכל קידומת נדרשת חייבים להתאים לתכנון ולמדיניות הייבוא שלו. פרסום חסר נראה בדיוק כמו מנהרה שבורה.

חיבור ה-VPN ושער המעבר הם כעת תשתית משותפת.

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

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