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 काम बंद स्वरूपात अपयशी व्हावे। नंतर एक बोगदा तोडा आणि काम फक्त त्या भाडेकरूसाठी अपयशी होते, दुसऱ्या ग्राहकाच्या त्याच-क्रमांकाच्या सबनेटवर पडत नाही याची खात्री करा। पुनर्संचयितीचीही चाचणी व्हावी, कारण जुना मार्ग किंवा कॅशे केलेले क्रेडेन्शियल व्यत्ययापेक्षा जास्त टिकू शकतात।
रचना वेगळ्या कनेक्टरसह सामायिक वर्कर किंवा पूर्णपणे वेगळी भाडेकरू संसाधने असू शकते। अपरिवर्तनीय एकच आहे: पडताळलेला भाडेकरू संदर्भ मार्ग आणि क्रेडेन्शियल निवडतो, आणि कोणताही मार्ग बदल कधीही भाडेकरूंमध्ये अनुप्रयोग परवानगी देत नाही।