Anypoint VPN કે Transit Gateway NAT: અનુવાદ ક્યાં થાય છે
Anypoint VPN પોતે સરનામાંનું ભાષાંતર કરતું નથી. NATનું વચન આપતા પહેલાં ફાયરવૉલ PAT, AWS પ્રીફિક્સ મેપ કે અલગ એટેચમેન્ટ વચ્ચે નિર્ણય કરો.
NATની જરૂરિયાત ત્યાં સુધી જરૂરિયાત નથી જ્યાં સુધી એ બદલાતાં સરનામાં અને એ બદલવાની પરવાનગી ધરાવતો ઘટક ન જણાવે. MuleSoft કનેક્ટિવિટીમાં એ નિર્ણયને ત્રણ ઇનપુટ છે: બેકએન્ડને ઘણા-થી-એક પોર્ટ અનુવાદ જોઈએ કે એક-થી-એક પ્રીફિક્સ ઉપનામ, તમે ખરેખર ધરાવતું AWS એટેચમેન્ટ એ મેપિંગ કરી શકે છે કે નહીં, અને આખો રસ્તો વેન્ડર સપોર્ટ કરતા સંયોજનમાં રહે છે કે નહીં. આ ખોટું થયું તો તમે કામ કરતી લેબ બનાવશો જે સમીક્ષામાં નિષ્ફળ જશે.
એક જ સ્થિર મુદ્દો એ છે કે Anypoint VPN પોતે અનુવાદનું ઉપકરણ નથી. CloudHub 2.0નું દસ્તાવેજીકરણ ત્યાં NATને અસમર્થિત તરીકે સૂચિબદ્ધ કરે છે, એટલે ટનલ તમારા વર્કર સરનામાં છુપાવશે એમ ધારતી કોઈપણ રચના પહેલેથી જ તૂટેલી છે.
અનુવાદે શું કરવું છે એ નક્કી કરો
જો ઘણા એપ્લિકેશન વર્કર્સ બેકએન્ડ સામે એક જ સરનામા તરીકે દેખાવા જોઈએ, તો જરૂરિયાત વહેંચાયેલ સ્રોત અનુવાદ છે, સામાન્ય રીતે તમે નિયંત્રિત કરતા ફાયરવૉલ પર સ્ટેટફુલ SNAT અથવા PAT. એ ઘટક મંજૂર રસ્તા પર બેસવો જોઈએ, ફ્લોના આખા જીવનકાળ દરમિયાન તેનું સ્ટેટ રાખવું જોઈએ અને તેણે ફરીથી લખેલા દરેક કનેક્શનનો પરત ટ્રાફિક જોવો જોઈએ. સેશન વચ્ચે સ્ટેટ ગુમાવવાથી કનેક્શન નબળું પડતું નથી; એ તેને સમાપ્ત કરે છે. અનુવાદ સ્ટેટ વહેંચવાનો ઇનકાર કરતી ફાયરવૉલ જોડી ફેઇલઓવર પછી સ્ટેન્ડબાય સભ્ય પર આવતું દરેક સેશન પડી ભાંગશે. એ ઘટકનું માપ સાથોસાથ ચાલતા ફ્લો માટે કરો, થ્રુપુટ માટે નહીં.
જો તેના બદલે બે નેટવર્ક ઓવરલેપ થાય અને દરેક હોસ્ટને અલગ ઉપનામ જોઈએ, તો જરૂરિયાત સ્પષ્ટ મેપ કરેલા પ્રીફિક્સ, મેળ ખાતા રૂટ અને મેપિંગ સાથે સહમત નામ-ઉકેલ સાથેની એક-થી-એક સરનામા યોજના છે. દરેક વર્કરને એક સરનામા પાછળ છુપાવવું એ તેનું સસ્તું સંસ્કરણ નથી, અને રચના સમીક્ષામાં એકને બીજા સાથે બદલવું એ પ્રોજેક્ટ ક્વાર્ટર ગુમાવવાનો રસ્તો છે.
ઉત્પાદન પસંદ કરતા પહેલાં નિર્ણય ચોક્કસ શબ્દોમાં નોંધો: મૂળ સ્રોત, મૂળ ગંતવ્ય, અનૂદિત મૂલ્ય, શરૂઆતની દિશા, અનુવાદકનો માલિક અને અપેક્ષિત જવાબ માર્ગ. બેકએન્ડ લોગ કઈ ઓળખ રાખશે એ પણ ઉમેરો, કારણ કે બધા સ્રોત છુપાવતી રચના ક્લાયન્ટ-વાર ઓડિટ પણ નષ્ટ કરે છે.
AWS તમારા વતી મેપિંગ કરી શકે છે કે નહીં એ તપાસો
AWS હવે Transit Gateway અને Cloud WAN એટેચમેન્ટ પર સંચાલિત એક-થી-એક NATનું દસ્તાવેજીકરણ કરે છે, જે 2026ના ઑક્ટોબરના અંતમાં જાહેર થયું, એટલે ટ્રાન્ઝિટ ગેટવે ક્યારેય અનુવાદ કરી શકતું નથી એ જૂનું સામાન્ય વિધાન અસ્તિત્વમાં નથી. Transit Gateway NAT દસ્તાવેજીકરણ સ્ટેટલેસ IPv4 પ્રીફિક્સ મેપિંગ વર્ણવે છે: મૂળ અને અનૂદિત પ્રીફિક્સ સમાન લંબાઈ રાખે છે, અને હોસ્ટ બિટ્સ તથા ટ્રાન્સપોર્ટ પોર્ટ અનુવાદમાં ટકી રહે છે. ઇનગ્રેસ અને એગ્રેસ દિશાઓને અલગ રચના-નિર્ણયો તરીકે વાંચો, કારણ કે તે અલગ રીતે ગોઠવાય છે અને એક તૈયાર હોઈ શકે જ્યારે બીજું ન હોય. એ વર્ણનમાં કંઈ પણ ફ્લો-વાર સ્ટેટ સૂચવતું નથી, એટલે મેપિંગ તમારા વતી કનેક્શન ટ્રૅક કરશે એમ ન ધારો.
એનો અર્થ છે કે 10.80.0.0/16ને 172.28.0.0/16 પર મેપ કરવાથી 10.80.10.23 172.28.10.23 બને છે. એ /16ને એક સરનામામાં સંકોચતું નથી અને PATની જરૂરિયાતને બદલતું નથી. એ પસંદ કરેલા એટેચમેન્ટ પ્રકારોને પણ આવરે છે, જેમાં VPC અને Site-to-Site VPN છે, પણ Client VPN એટેચમેન્ટને નહીં, અને રૂપરેખાંકન ટ્રાન્ઝિટ ગેટવેના માલિક પાસે રહે છે, Anypoint બાજુ પાસે નહીં.
આ સુવિધાને વધુ એક શક્ય નિયંત્રણ-બિંદુ તરીકે ગણો, તમારું ડિપ્લોયમેન્ટ એનો ઉપયોગ કરી શકે છે એના પુરાવા તરીકે નહીં. CloudHub 2.0 ગ્રાહકના પોતાના AWS ખાતામાં ટ્રાન્ઝિટ ગેટવે પર ખાનગી-જગ્યા એટેચમેન્ટનું દસ્તાવેજીકરણ કરે છે, પ્રાદેશિક અને હક્કની શરતો સાથે, એટલે નવા વિકલ્પની આસપાસ રચના કરતા પહેલાં વાસ્તવિક એટેચમેન્ટ પ્રકાર, તેનો માલિક અને વેન્ડરનું સપોર્ટ વલણ પુષ્ટિ કરો.
માર્ગને સપોર્ટેડ સીમાની અંદર રાખો
ફાયરવૉલ અનુવાદક માટે, ચાલતી ટનલમાં સામાન્ય NAT નિયમ ચોંટાડવાને બદલે એ ઉત્પાદનનું સપોર્ટેડ VPN, અનુવાદ અને રૂટિંગ મોડલ વાપરો. બેકએન્ડનો જવાબ એ જ અનુવાદ ઘટકમાંથી પાછો આવવો જોઈએ, અને સ્વસ્થ આઉટબાઉન્ડ ટનલ એ પરત માર્ગ વિશે કંઈ કહેતું નથી.
ટ્રાન્ઝિટ ગેટવે માર્ગ માટે, ખાનગી-જગ્યા એટેચમેન્ટ, સંબંધિત રૂટ કોષ્ટકો, ઑન-પ્રેમિસ એટેચમેન્ટ અને ગ્રાહક ખરેખર ગોઠવી શકે તે ભાગોની યાદી બનાવો. આ અલગ કનેક્ટિવિટી આર્કિટેક્ચર છે, હાલના Anypoint VPN કનેક્શન પર બોલ્ટ કરેલું NAT ચેકબોક્સ નથી, અને સપોર્ટ સીમા એની સાથે ખસે છે.
ત્રણ વિકલ્પોની એક કોષ્ટકમાં તુલના કરો
મોટાભાગની ટીમોએ ફક્ત બે પ્રશ્નોના જવાબ આપવા પડે છે: ઘણા-થી-એક કે એક-થી-એક, અને એટેચમેન્ટનો માલિક કોણ છે. નીચેનું કોષ્ટક એ જવાબોને શરૂઆતના વિકલ્પમાં ફેરવે છે.
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
ત્રીજા સ્તંભને પછીના વિચાર તરીકે નહીં, સમીક્ષાના પ્રશ્ન તરીકે વાંચો. કાગળ પર મંજૂર પણ તમારી માલિકીના ન હોય એવા એટેચમેન્ટ પર ગોઠવેલો પ્રીફિક્સ મેપ હજી અવરોધિત પ્રોજેક્ટ છે, અને ટ્રાફિક પસાર કરતો પણ ક્લાયન્ટ-વાર લોગિંગ તોડતો PAT નિયમ પછીની ઓડિટમાં નિષ્ફળ જાય છે.
વચન આપતા પહેલાં મેપિંગની ચકાસણી કરો
માર્ગમાંથી એક નવું એપ્લિકેશન ઑપરેશન મોકલો અને ફક્ત વિનંતી નહીં, જવાબ પણ પુષ્ટિ કરો. બેકએન્ડ માલિકને પૂછો કે તેમના લોગે કયું સ્રોત સરનામું નોંધ્યું, બંને દિશામાં સરનામા-કુટુંબની હેન્ડલિંગ યોજના સાથે મેળ ખાય છે કે નહીં તપાસો, અને જે માર્ગ નકારવો જોઈએ તે હજી નકારાય છે એ ચકાસો. જૂનું કનેક્શન તમે હમણાં બદલેલા મેપિંગ વિશે કંઈ પણ સાબિત કરતું નથી.
બેકએન્ડની પ્રમાણીકરણ તેની મંજૂર-સૂચિ સંતોષતા કોઈપણ અનૂદિત સરનામાથી સ્વતંત્ર રાખો, કારણ કે મેપિંગ નેટવર્કની પ્લમ્બિંગ છે, ઍક્સેસ-નિયંત્રણનો નિર્ણય નથી. જે ક્ષણે પાસવર્ડ રીસેટ NAT પ્રીફિક્સ પર આધારિત થાય, ત્યારે દરેક ભાવિ રેન્જ ફેરફાર બંધ પડવાનો બની જાય છે.
મંજૂરી પહેલાં ત્રણ જવાબ લખો: અનુવાદનો પ્રકાર, અનુવાદકનો માલિક, અને એને વહન કરતું સપોર્ટેડ એટેચમેન્ટ કે ઉત્પાદન માર્ગ. જો એમાંથી કોઈ પણ હજી અનુમાન હોય, તો રચના ફેરફાર-વિન્ડો માટે તૈયાર નથી.