AWS નું NAT ગેટવે VPN તરફ કયું સ્રોત IP વાપરે છે?

તમે VPC કન્સોલ ખોલો છો કારણ કે ભાગીદારે પૂછ્યું કે સાઇટ-ટુ-સાઇટ VPN દ્વારા કઈ સ્રોત શ્રેણી આવશે. NAT ગેટવે પૃષ્ઠ Elastic IP જોડાયેલું જાહેર ગેટવે બતાવે છે, અને લાલચ એ છે કે તે સરનામું મોકલીને આગળ વધવું. ઇન્ટરનેટ માર્ગ માટે તે સાચો જવાબ છે અને VPN માર્ગ માટે ખોટો જવાબ છે, અને ફરક એ છે કે રૂટ ટેબલ કયા ગેટવે તરફ ઇશારો કરે છે. મંજૂર યાદી લખતા પહેલાં માર્ગ ચાલી જુઓ.

મંજૂર યાદીથી નહીં, NAT ગેટવે પૃષ્ઠથી શરૂ કરો

NAT ગેટવે પૃષ્ઠ તમને સબનેટ, પ્રકાર અને Elastic IP જણાવે છે, અને તે ત્રણ ક્ષેત્રો શરૂ કરવા માટે પૂરતા છે. જે તે જણાવતું નથી તે છે ટ્રાફિક પછી લેતો માર્ગ. તે NAT ગેટવેના સબનેટ સાથે જોડાયેલા રૂટ ટેબલમાંથી આવે છે.

પહેલા પ્રકાર વાંચો, કારણ કે જાહેર કે ખાનગી એ નક્કી કરે છે કે પછીથી સાંકળમાં ઇન્ટરનેટ ગેટવે દેખાશે કે નહીં. પછી સબનેટ વાંચો, કારણ કે બીજો માર્ગ ત્યાં જ રહે છે.

બે રૂપાંતરણો અનુસરો

જાહેર અને ખાનગી બંને NAT ગેટવે વર્કલોડના ખાનગી IPv4 સ્રોતને NAT ગેટવેના પોતાના ખાનગી IPv4 સરનામામાં રૂપાંતરિત કરે છે. તે પહેલું રૂપાંતરણ પ્રકારને ધ્યાનમાં લીધા વિના થાય છે. બીજું રૂપાંતરણ એ છે જે લોકો ભૂલી જાય છે: જાહેર NAT ગેટવે ટ્રાફિક ઇન્ટરનેટ ગેટવેને સોંપે છે, જે સરનામાને જોડાયેલા Elastic IP સાથે મેપ કરે છે.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

ખાનગી માર્ગમાં સાંકળમાં કોઈ ઇન્ટરનેટ ગેટવે નથી. જ્યારે ટ્રાફિક ટ્રાન્ઝિટ ગેટવે અથવા વર્ચ્યુઅલ ખાનગી ગેટવે દ્વારા બહાર જાય છે, ત્યારે NAT ગેટવે માર્ગદર્શિકા NAT ગેટવેના ખાનગી સરનામાને દૂરના છેડાને મળતા સ્રોત તરીકે દસ્તાવેજ કરે છે. ભાગીદારે તે સરનામાને મંજૂરી આપવી જોઈએ, Elastic IP ને નહીં.

VPN માર્ગ સામાન્ય રીતે ખાનગી સરનામું બતાવે છે

10.20.1.0/24 માં રહેલા વર્કલોડ માટે જે ભાગીદારના પ્રીફિક્સ સુધી પહોંચે છે, વર્કલોડ સબનેટનું રૂટ ટેબલ NAT ગેટવે તરફ અને NAT ગેટવેના સબનેટનું રૂટ ટેબલ ખાનગી ગેટવેના માર્ગ તરફ ઇશારો કરે છે. બંને હોપ મહત્ત્વના છે, અને ફક્ત બીજો જ નક્કી કરે છે કે ભાગીદાર શું જુએ છે. જો NAT સબનેટ પાસે VPN માર્ગ તરફ કોઈ રૂટ ન હોય, તો પેકેટ ક્યારેય પહોંચતું નથી, અને તે ખોટા સ્રોત સરનામા કરતાં અલગ નિષ્ફળતા છે.

સરનામાં વિશે બોલવા પહેલાં જ તે બીજો માર્ગ ચકાસો. ગેરહાજર માર્ગ અને ખોટી રીતે જણાવાયેલો સ્રોત ફક્ત ટ્રાફિક ન જોતા ભાગીદાર માટે એકદમ સરખા દેખાય છે.

જ્યારે બીજું રૂપાંતરણ જવાબ બદલે છે

AWS ટ્રાન્ઝિટ ગેટવે જોડાણ પર સ્પષ્ટ, મેળ ખાતું એક-થી-એક NAT મેપિંગ પણ આપે છે. તે મેપિંગ દૂરની સેવા જોતા પહેલાં સ્રોતને ફરી રૂપાંતરિત કરી શકે છે, અને તે ફક્ત રૂટ કરતું મૂળભૂત વર્તન નથી. કારણ કે તે જાણી જોઈને ગોઠવવું પડે છે, તેને ડિઝાઇન અપવાદ તરીકે ગણો, અકસ્માતે વારસામાં મળતી વસ્તુ તરીકે નહીં. જો તમારી ટીમમાં કોઈને યાદ ન હોય કે તે ચાલુ કર્યું હતું, તો જોડાણ વાંચ્યા સુધી તે ગેરહાજર માની લો.

જો તમારી ડિઝાઇન તેનો ઉપયોગ કરે, તો મંજૂર યાદીએ NAT ગેટવેનું સરનામું નહીં, અંતિમ મેપિંગ વર્ણવવું જોઈએ. એ જ સાવચેતી ઉપલબ્ધતા માર્ગોને પણ લાગુ પડે છે: જ્યારે ઘણાં ગેટવે સરનામાં ભાગ લે, ત્યારે અપેક્ષિત સ્રોત સમૂહ એ જોડાણ છે, કોઈ એક પ્રતિનિધિ સરનામું નહીં. દરેક સરનામું કયા રૂપાંતરણનું છે તે લખો, કારણ કે ઉદ્ગમ વગરની યાદી પછીથી ઓડિટ કરવી અશક્ય છે.

ખાનગી NAT ગેટવેને ઇન્ટરનેટ ગેટવે તરફ નિર્દેશ કરીને ઇન્ટરનેટ સેવા આપી શકાતી નથી; AWS દસ્તાવેજ કરે છે કે એવો ટ્રાફિક ફેંકી દેવાય છે. પ્રકાર સંપૂર્ણ માર્ગ પરથી પસંદ કરો, જરૂરિયાતના VPN શબ્દ પરથી નહીં.

તમારો ભાગીદાર જેના પર કાર્ય કરી શકે એવો કરાર લખો

ઉપયોગી કરારમાં ચાર ભાગ હોય છે: પ્રવાહ કઈ દિશાથી શરૂ થાય છે, ભાગીદાર જે રૂપાંતરિત ઓળખ જોશે, તે ઓળખ માટેનો પરત માર્ગ, અને લાગુ પડતો રક્ષણ વિસ્તાર. NAT ગેટવેના પ્રવાહ સમર્થિત ઉદ્ગમ બાજુથી શરૂ થાય છે, તેથી આ ખાનગી વર્કલોડ ખુલ્લો કરવા માટેની આવક પોર્ટ ફોરવર્ડિંગ સેવા નથી. તેને વહેલા મોટેથી કહેવાથી એવી ડિઝાઇન સમીક્ષા અટકે છે જેમાં દરેક પક્ષ ધારે કે બીજો પક્ષ શરૂ કરી રહ્યો છે.

રૂપાંતરણ સરનામાં ઓવરલેપમાંથી રાહત અને અનુમાનિત સ્રોત નીતિ ખરીદે છે, અને ભાગીદારના લોગમાં વ્યક્તિગત વર્કલોડ ઓળખ તમને ખર્ચ કરાવે છે. જો ઓડિટને વર્કલોડ દીઠ એટ્રિબ્યુશન જોઈએ, તો તે ઓળખ રૂપાંતરિત સ્રોત સરનામામાંથી પુનઃપ્રાપ્ત કરવાના બદલે એપ્લિકેશન સ્તરે રાખો.

પછી કોઈપણ ફેરફાર પછી બંને રૂટ ટેબલ ફરી ચકાસો, કારણ કે નવું જોડાણ અથવા ફરી જોડાયેલું સબનેટ જવાબ ચૂપચાપ ફરી લખે છે.