EC2 Elastic IP ઇન્સ્ટન્સનું ખાનગી VPN સરનામું નથી

ઇન્સ્ટન્સનું ખાનગી સરનામું છે, Elastic IP તેની સાથે સંકળાયેલું છે, અને તે પબ્લિક /32 માટેનો રૂટ VPNમાં ઉમેરવામાં આવે છે એ આશામાં કે બંને એક જ વસ્તુ બની જશે. તેઓ બનતા નથી. Elastic IP એ ગેસ્ટની બહાર, ઇન્ટરનેટ ગેટવે દ્વારા, ઇન્ટરનેટ માર્ગ લેતા ટ્રાફિક પર કરવામાં આવતો અનુવાદ છે. ગેસ્ટનું ઓપરેટિંગ સિસ્ટમ તે સરનામું ક્યારેય કોઈ ઇન્ટરફેસ પર ગોઠવાયેલું જોતું નથી. તેને ટનલ ઇન્ટરફેસ પર ઉમેરવાથી ઉપરનો અનુવાદ પુનઃઉત્પન્ન થતો નથી અને તે જ મશીન માટે બીજી, વિરોધાભાસી ઓળખ બનાવે છે.

બે સરનામાં, એક ઇન્સ્ટન્સ

ઇન્સ્ટન્સનું નેટવર્ક ઇન્ટરફેસ VPCની અંદર ખાનગી સરનામું ધરાવે છે, અને તે જ સરનામું છે જે ગેસ્ટ જાણે છે. Elastic IP તે જ ઇન્ટરફેસ સાથે સંકળાયેલું છે પણ મેપિંગની પબ્લિક બાજુ પર રહે છે.

ઇન્ટરનેટ દ્વારા ઇન્સ્ટન્સ સુધી પહોંચતું બધું ખાનગી સરનામા પર અનુવાદિત થઈને આવે છે. ઇન્સ્ટન્સ ઇન્ટરનેટ પર મોકલે છે તે બધું Elastic IPને સ્રોત તરીકે લઈને નીકળે છે, ફરીથી તે જ અનુવાદને કારણે.

ગેસ્ટની અંદર એક સરનામું અસ્તિત્વમાં છે. બહાર બે છે. તે અસમાનતા આ ક્ષેત્રની મોટાભાગની ગૂંચવણ સમજાવે છે. ગેસ્ટ ગેટવે શું અનુવાદ કરે છે તે ગોઠવી શકતું નથી. તે ફક્ત તે સરનામા પર જ જવાબ આપી શકે છે જે ખરેખર તેની પાસે છે.

ઇન્ટરનેટ ગેટવે ખરેખર શું કરે છે

AWSનું ઇન્ટરનેટ ગેટવે દસ્તાવેજીકરણ આ ગોઠવણ વર્ણવે છે: ઇન્સ્ટન્સ તેના ખાનગી IPv4 સરનામાથી વાકેફ છે, અને ગેટવે ઇન્ટરનેટ માર્ગ પરના ટ્રાફિક માટે અનુરૂપ પબ્લિક IPv4 અથવા Elastic IP અનુવાદ પ્રદાન કરે છે.

તે નેટવર્ક સરનામા અનુવાદ છે, ઉપનામ નથી. મેપિંગ ગેટવે જાળવે છે, તે સંલગ્નતા સાથે બંધાયેલું છે અને ફક્ત તેમાંથી પસાર થતા પેકેટોને લાગુ પડે છે. સંલગ્નતા દૂર કરો અને પબ્લિક ઓળખ અદૃશ્ય થઈ જાય છે, ગેસ્ટને કંઈ ખબર પડતી નથી.

તેથી જ પબ્લિક /32 પર સંબોધિત ખાનગી VPN પેકેટને ગેસ્ટના સ્થાનિક સરનામા પર જતા ખાનગી પેકેટ તરીકે ફરીથી અર્થઘટન કરવામાં આવતું નથી. પેકેટ જે રૂટ સાથે મેળ ખાય છે તેને અનુસરે છે, જે તેને ઇન્ટરનેટ ગેટવે પર મોકલે છે, અને ગેટવેનું વર્તન એના પર આધાર રાખે છે કે માર્ગ બંને દિશામાં માન્ય છે કે નહીં.

ટનલ ઇન્ટરફેસની યુક્તિ કેમ નિષ્ફળ જાય છે

Elastic IPને ટનલ ઇન્ટરફેસ પર સોંપવાથી ગેસ્ટને પબ્લિક સરનામાને સ્થાનિક ગણવાનું કહેવાય છે. હવે બે વસ્તુઓ એક જ સરનામાનો દાવો કરે છે: ઇન્ટરનેટ માર્ગ પર ગેટવેનો અનુવાદ અને ટનલની અંદરનું સ્થાનિક ઇન્ટરફેસ. પરત ટ્રાફિક પાસે કયું લાગુ પડે છે તેનો સુસંગત જવાબ નથી.

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

સરનામું ક્યારેય સમસ્યા ન હતું. માર્ગની પસંદગી હતી.

ત્રણ લક્ષ્યો, ત્રણ ડિઝાઇન

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

જો લક્ષ્ય એપ્લિકેશનની ખાનગી ઍક્સેસ હોય, તો ગંતવ્ય ખાનગી સરનામું અથવા તેના પર રિઝોલ્વ થતું ખાનગી DNS નામ છે, અને VPN રૂટ, સિક્યોરિટી ગ્રુપ અને પરત માર્ગ બધાએ સહમત થવું પડે. Elastic IP તે ડિઝાઇનમાં બિલકુલ દેખાતું નથી.

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

તમે પસંદ કરેલો માર્ગ ચકાસો

ખાનગી ઍક્સેસ માટે ખાતરી કરો કે VPN રૂટ ખાનગી પ્રીફિક્સને આવરે છે, VPC રૂટ ટેબલ ટ્રાફિકને ટનલ પર પાછો મોકલે છે, સિક્યોરિટી ગ્રુપ ક્લાયન્ટના સ્રોતને મંજૂરી આપે છે અને ક્લાયન્ટનું પોતાનું ફાયરવોલ જવાબને મંજૂરી આપે છે. પછી pingને બદલે એક વાસ્તવિક વિનંતીનું પરીક્ષણ કરો.

પબ્લિક ઍક્સેસ માટે ક્લાયન્ટનું ઇન્ટરનેટ એગ્રેસ, પબ્લિક એન્ટ્રીનું રૂટિંગ અને તેની સિક્યોરિટી પોલિસી ચકાસો. VPN ક્લાયન્ટ ટનલ દ્વારા પબ્લિક એન્ડપોઇન્ટ સુધી પહોંચી શકે છે કે નહીં તે ટનલના એગ્રેસ અને ફાયરવોલ નિયમો પર આધાર રાખે છે, Elastic IP સંલગ્નતા પર નહીં.

જો પબ્લિક હોસ્ટનામ બંને બાજુથી કામ કરવું પડે, તો એવી DNS ડિઝાઇન વાપરો જે VPN ક્લાયન્ટ્સ માટે ખાનગી સરનામાથી અને બીજા સૌ માટે પબ્લિક સરનામાથી જવાબ આપે, અને પ્રમાણપત્રને સરનામાને બદલે નામ માટે માન્ય રાખો. કામનો ક્રમ: લક્ષ્યનું નામ આપો, તેનું સરનામું પસંદ કરો, પછી રૂટ, પોલિસી અને એક વિનંતી ચકાસો.