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 काम बन्द रूपमा असफल हुनुपर्छ। त्यसपछि एउटा सुरुङ तोड्नुहोस् र काम त्यो भाडावालका लागि मात्र असफल हुन्छ, अर्को ग्राहकको उही-नम्बर सबनेटमा फर्किँदैन भनी पुष्टि गर्नुहोस्। पुनःस्थापनाको पनि परीक्षण गर्नुपर्छ, किनभने पुरानो मार्ग वा क्यास गरिएको प्रमाणपत्र अवरोधभन्दा लामो टिक्न सक्छ।
संरचना अलग कनेक्टरसहित साझा वर्कर वा पूर्ण रूपमा छुट्टै भाडावाल स्रोतहरू हुन सक्छ। अपरिवर्तनीय एकै हो: प्रमाणित भाडावाल सन्दर्भले मार्ग र प्रमाणपत्र छान्छ, र कुनै पनि मार्ग परिवर्तनले कहिल्यै भाडावालबीच अनुप्रयोग अनुमति दिँदैन।