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 કાર્ય બંધ રીતે નિષ્ફળ થવું જોઈએ. પછી એક ટનલ તોડો અને પુષ્ટિ કરો કે કાર્ય ફક્ત તે ટેનન્ટ માટે નિષ્ફળ થાય છે, બીજા ગ્રાહકના સમાન-ક્રમાંકિત સબનેટ પર પાછું ન પડતાં. પુનઃસ્થાપન પણ ચકાસવું જોઈએ, કારણ કે જૂનું રૂટ કે કેશ કરેલ ક્રેડેન્શિયલ વિક્ષેપથી વધુ ટકી શકે છે.
આર્કિટેક્ચર આઇસોલેટેડ કનેક્ટર સાથે પૂલ કરેલ વર્કર અથવા સંપૂર્ણ અલગ ટેનન્ટ સંસાધનો હોઈ શકે છે. અપરિવર્તક એક જ છે: ચકાસાયેલ ટેનન્ટ સંદર્ભ રૂટ અને ક્રેડેન્શિયલ પસંદ કરે છે, અને કોઈ રૂટ ફેરફાર ક્યારેય ટેનન્ટ વચ્ચે એપ્લિકેશન પરવાનગી આપતું નથી.