SaaS ट्रैफ़िक को सही ग्राहक VPN तक कैसे रूट करें
ओवरलैप करने वाले ग्राहक सबनेट साझा रूटिंग को तोड़ते हैं। कोई आइसोलेशन मॉडल चुनें, हर कार्य को सत्यापित टेनेंट से बाँधें, और लॉन्च से पहले क्रॉस-टेनेंट पथों की जाँच करें।
एक SaaS प्लेटफ़ॉर्म एक दर्जन ग्राहक नेटवर्कों से जुड़ता है, और उनमें से दो ग्राहक अपने प्राथमिक डेटाबेस के लिए दोनों 10.20.0.10 का उपयोग करते हैं। किसी कार्य में वह पता पाने वाले वर्कर के पास यह जानने का कोई तरीका नहीं होता कि कार्य किस डेटाबेस का मतलब है, और एक साझा रूटिंग तालिका उसे खुशी-खुशी उसी टनल में भेज देगी जिसकी ओर प्रीफ़िक्स इशारा करता है। समाधान और टनल नहीं हैं; समाधान यह तय करना है कि टेनेंट पहचान पथ में कहाँ प्रवेश करती है और पता योजना को कौन-सा आइसोलेशन मॉडल चाहिए। तीन शर्तें यह चुनाव तय करती हैं: ग्राहक प्रीफ़िक्स ओवरलैप करते हैं या नहीं, कोई गलती कितनी दूर फैल सकती है, और कनेक्टर कौन चलाता है।
दो ग्राहक डेटाबेस, एक गंतव्य पता
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 को Transit Gateway और Cloud WAN के लिए अटैचमेंट-स्तरीय 1:1 NAT जोड़ा, जो समर्थित अटैचमेंट के लिए ओवरलैप का उत्तर बदल देता है। Transit Gateway NAT दस्तावेज़ीकरण होस्ट बिट सुरक्षित रखते हुए स्थिर, अवस्थाहीन, समान-प्रीफ़िक्स IPv4 मैपिंग का वर्णन करता है। इसके आसपास डिज़ाइन करने से पहले समर्थित अटैचमेंट प्रकार और क्षेत्रीय सीमाएँ जाँचें।
कार्य को सत्यापित टेनेंट से बाँधें
हर कार्य में सर्वर-सत्यापित टेनेंट पहचान होनी चाहिए, और उस पहचान को प्रशासक के स्वामित्व वाला कनेक्शन रिकॉर्ड चुनना चाहिए। रिकॉर्ड स्वीकृत नेटवर्क संदर्भ, सेवा पता, क्रेडेंशियल संदर्भ और वहाँ अनुमत संचालनों के नाम बताता है। एक अविश्वसनीय अनुरोध को कभी भी अपना VPN पहचानकर्ता, गेटवे या निजी लक्ष्य नहीं देना चाहिए, क्योंकि वैध लॉगिन हर जुड़े ग्राहक के पता स्थान की जाँच करने की अनुमति नहीं है।
आइसोलेटेड कनेक्टर डिज़ाइन में, टेनेंट A का कार्य A-विशिष्ट कनेक्टर पर जाता है जो A के VPC में चलता है और केवल A के स्वीकृत संसाधनों तक पहुँच सकता है। एक ही होस्ट पर अलग कंटेनर अपने आप वह अलगाव नहीं बनाते; नेटवर्क नेमस्पेस, रूट और इग्रेस नीति को उसे लागू करना होता है। कनेक्टर को टेनेंट-सीमित क्रेडेंशियल और क्यू भी चाहिए, क्योंकि निजी रूट साझा रहस्य या साझा कार्य आइटम को सीमित नहीं करता। पूल किए गए एप्लिकेशन वर्कर ठीक हैं जब तक नेटवर्क संदर्भ और क्रेडेंशियल प्रति टेनेंट चुने जाएँ, प्रति होस्ट नहीं।
स्वास्थ्य जाँचें टेनेंट और चरण का नाम बताएँ: टनल स्थापित, रूट मौजूद और वास्तविक सेवा अनुरोध सफल तीन अलग संकेत हैं। चालू टनलों की कुल गिनती उस एक ग्राहक को छिपा देगी जिसका कनेक्टर टूटा है।
उन पथों की जाँच करें जिन्हें विफल होना चाहिए
लॉन्च से पहले तीन परीक्षण चलाएँ। अनुमत A संचालन सफल होना चाहिए, अनुमत B संचालन सफल होना चाहिए, और जानबूझकर B के कनेक्टर या उसके अनूदित उपनाम की ओर निर्देशित A कार्य बंद रूप से विफल होना चाहिए। फिर एक टनल तोड़ें और पुष्टि करें कि कार्य केवल उसी टेनेंट के लिए विफल होता है, किसी दूसरे ग्राहक के समान-संख्या वाले सबनेट पर वापस गिरे बिना। पुनर्स्थापन भी जाँचा जाना चाहिए, क्योंकि पुराना रूट या कैश किया हुआ क्रेडेंशियल व्यवधान से अधिक जी सकते हैं।
आर्किटेक्चर आइसोलेटेड कनेक्टर वाले पूल किए गए वर्कर या पूरी तरह अलग टेनेंट संसाधन हो सकता है। अपरिवर्तनीय बात एक ही है: सत्यापित टेनेंट संदर्भ रूट और क्रेडेंशियल चुनता है, और कोई रूट परिवर्तन कभी भी टेनेंट के बीच एप्लिकेशन अनुमति नहीं देता।