כיצד לנתב תעבורת SaaS אל ה-VPN הנכון של הלקוח
תת-רשתות חופפות של לקוחות שוברות ניתוב משותף. בחרו מודל בידוד, קשרו כל משימה לדייר מאומת, ובדקו נתיבים בין דיירים לפני ההשקה.
פלטפורמת SaaS מתחברת לשנים עשר רשתות של לקוחות, ושניים מאותם לקוחות משתמשים שניהם ב-10.20.0.10 עבור מסד הנתונים הראשי שלהם. Worker שמקבל את הכתובת הזו במשימה אינו יכול לדעת לאיזה מסד נתונים המשימה מתכוונת, וטבלת ניתוב משותפת תשלח אותו בשמחה למנהרה שהקידומת מצביעה עליה. הפתרון אינו עוד מנהרות; הפתרון הוא להחליט היכן זהות הדייר נכנסת לנתיב ואיזה מודל בידוד תוכנית הכתובות דורשת. שלושה תנאים מכריעים את הבחירה: אם קידומות הלקוחות חופפות, עד כמה רחוק טעות יכולה להתפשט, ומי מפעיל את המחבר.
שני מסדי נתונים של לקוחות, כתובת יעד אחת
כתובת IP היא מיקום, לא זהות. הבקשה חייבת לשאת דייר שהשרת אימת, ודייר זה חייב לבחור את הקשר הרשת לפני שהיעד נפתר.
כשזה לא קורה, הכשל שקט. החיבור מצליח, השאילתה רצה, והתשובה מגיעה ממסד הנתונים של הלקוח הלא נכון כי לטבלת הניתוב הייתה רשומה אחת עבור 10.20.0.10. DNS מחמיר את המצב: שם שנשמר במטמון ונפתר בהקשר של דייר A יכול לשמש מחדש משימה שרצה עבור דייר B. שום דבר בחבילה לא מבדיל בין השניים, ולכן שום לוגיקת ניסיון חוזר לא מתקנת זאת.
החליטו קודם על מודל הבידוד
רשמו את שלושת התנאים לפני השוואת מוצרים. החפיפה מחליטה אם אפשר לשתף מרחב כתובות אחד בכלל; רדיוס הפגיעה מחליט אם טעות ניתוב היא כרטיס תמיכה או פרצה; הבעלות התפעולית מחליטה אם אתם יכולים להפעיל צי מחברים לכל דייר.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
אם הקידומות נפרדות והמדיניות מאפשרת רכז מבוקר, Transit Gateway אחד עם טבלאות ניתוב לכל דייר הוא ישים. שיוך הצירוף בוחר את טבלת הניתוב המשמשת לתעבורה שנכנסת מאותו צירוף, וההפצה בוחרת אילו נתיבים מופיעים בטבלה. צירוף של דייר המשויך רק לטבלה שלו ומפיץ רק את הקידומות שלו מגיע לרכז ולשום מקום אחר. זו החלטת ניתוב, והיא נשארת נכונה רק כל עוד אף אחד לא מוסיף נתיב ברירת מחדל לטבלה המשותפת.
אם הקידומות חופפות, ניתוב לבדו לא יכול להפריד ביניהן. אתם צריכים הקשר רשת נפרד לכל דייר או תוכנית תרגום שנותנת למרחב של כל לקוח משמעות חד-משמעית.
מה באמת אומר בידוד של Transit Gateway
שיוך והפצה הם שני הכפתורים החשובים, וקל להתבלבל ביניהם. שיוך עונה באיזו טבלה מחפשים חבילה מהצירוף הזה; הפצה עונה אילו טבלאות לומדות את הנתיבים של הצירוף הזה. הבידוד נובע מהפיכת שניהם לספציפיים לדייר, לא מיצירת צירופים נוספים.
תצורת ברירת מחדל של הכול-אל-הכול נוחה ואינה בידוד. טבלאות ניתוב נפרדות מגבילות קישוריות, אבל הן לא נותנות לכתובת יעד אחת ללא שינוי שתי משמעויות בתוך אותו הקשר ניתוב. אם היישום פותר את 10.20.0.10 לפני שהוא יודע את הדייר, שכבת הניתוב כבר איבדה את המידע שהיה דרוש לה.
AWS הוסיפה ב-23 באוקטובר 2026 NAT 1:1 ברמת הצירוף עבור Transit Gateway ו-Cloud WAN, מה שמשנה את תשובת החפיפה עבור צירופים נתמכים. תיעוד ה-NAT של Transit Gateway מתאר מיפויי IPv4 סטטיים, חסרי מצב ושווי קידומת עם שמירת סיביות המארח. בדקו את סוגי הצירופים הנתמכים ואת המגבלות האזוריות לפני שתעצבו סביב זה.
קשרו את המשימה לדייר מאומת
כל משימה צריכה לשאת זהות דייר מאומתת על ידי השרת, וזהות זו צריכה לבחור רשומת חיבור בבעלות המנהל. הרשומה מפרטת את הקשר הרשת המאושר, את כתובת השירות, את ההפניה לאישורים ואת הפעולות המותרות שם. בקשה לא מהימנה אסור לה לספק לעולם מזהה VPN, שער או יעד פרטי משלה, כי התחברות תקפה אינה הרשאה לבדוק את מרחב הכתובות של כל לקוח מחובר.
בעיצוב של מחברים מבודדים, העבודה של דייר A הולכת למחבר ספציפי ל-A שרץ ב-VPC של A ויכול להגיע רק למשאבים המאושרים של A. מכולות נפרדות על מארח אחד אינן יוצרות את ההפרדה הזו בעצמן; מרחבי השמות של הרשת, הנתיבים ומדיניות היציאה חייבים ליישם אותה. המחבר זקוק גם לאישורים ולתורים מוגבלים לדייר, כי נתיב פרטי אינו מגביל סוד משותף או פריט עבודה משותף. עובדי יישום משותפים בסדר כל עוד הקשר הרשת והאישורים נבחרים לפי דייר ולא לפי מארח.
בדיקות תקינות צריכות לציין את הדייר ואת השלב: מנהרה שהוקמה, נתיב שקיים ובקשת שירות אמיתית שהצליחה הם שלושה אותות שונים. ספירה כוללת של מנהרות פעילות תסתיר את הלקוח היחיד שהמחבר שלו שבור.
בדקו את הנתיבים שחייבים להיכשל
הריצו שלושה מבחנים לפני ההשקה. פעולת A מותרת חייבת להצליח, פעולת B מותרת חייבת להצליח, ומשימת A שמכוונת בכוונה למחבר של B או לשם הנרדף המתורגם שלו חייבת להיכשל סגור. לאחר מכן שברו מנהרה אחת וודאו שהמשימה נכשלת רק עבור אותו דייר, בלי ליפול לתת-הרשת בעלת אותו מספר של לקוח אחר. יש לבדוק גם שחזור, כי נתיב מיושן או אישור שמור במטמון יכולים לשרוד את התקלה.
הארכיטקטורה יכולה להיות עובדים משותפים עם מחברים מבודדים, או משאבי דייר נפרדים לחלוטין. האינווריאנט זהה: הקשר דייר מאומת בוחר את הנתיב ואת האישורים, ושום שינוי נתיב לא מעניק אי פעם הרשאת יישום בין דיירים.