ઓન-પ્રિમાઇસીસ ક્લાયન્ટ માટે S3 ગેટવે કે ઇન્ટરફેસ એન્ડપોઇન્ટ?

સાઇટ VPN દ્વારા ઓફિસ નેટવર્કમાંથી S3 સુધી પહોંચવું એ એવી રૂટિંગ સમસ્યા નથી જે સ્ટેટિક રૂટ એકલો ઉકેલી શકે. ગેટવે એન્ડપોઇન્ટ રૂટ ટેબલ સાથે જોડાયેલું હોય છે અને VPCની અંદર ઉદ્ભવતી વિનંતીઓને સેવા આપે છે. ઇન્ટરફેસ એન્ડપોઇન્ટ તમારા સબનેટમાં ખાનગી સરનામાં સાથે ઇલાસ્ટિક નેટવર્ક ઇન્ટરફેસ મૂકે છે, અને તે સરનામાં સુધી VPN કે Direct Connect દ્વારા ઓન-પ્રિમાઇસીસથી પહોંચી શકાય છે. વિનંતી ક્યાંથી શરૂ થાય છે તે નક્કી કરે છે કે તમને ખરેખર બેમાંથી કયું જોઈએ, અને DNS, સિક્યોરિટી ગ્રુપ તથા નીતિનું કામ તે જવાબમાંથી આવે છે.

વિનંતી ક્યાંથી શરૂ થાય છે તેના આધારે એન્ડપોઇન્ટના પ્રકાર અલગ કરો

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

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

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

નામને બદલે Type કોલમ વાંચો. એક જ VPC સામાન્ય રીતે એક જ સેવા માટે બંને પ્રકાર રાખે છે, અને તમારી ઓન-પ્રિમાઇસીસ એપ્લિકેશનને જે એન્ટ્રી જોઈએ છે તે ઇન્ટરફેસની છે.

S3 ચકાસતા પહેલાં ઇન્ટરફેસ સરનામા સુધીનો માર્ગ બનાવો

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

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

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

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

એપ્લિકેશનને કયો DNS જવાબ મળે છે તે નક્કી કરો

VPCમાં ઇન્ટરફેસ એન્ડપોઇન્ટ હોવું એ પોતાની રીતે ઓન-પ્રિમાઇસીસ SDKને રીડાયરેક્ટ કરતું નથી. ક્લાયન્ટ કાં તો AWS જે એન્ડપોઇન્ટ-વિશિષ્ટ નામ તે એન્ડપોઇન્ટ માટે પ્રકાશિત કરે છે તે વાપરે છે, અથવા તો ખાનગી હોસ્ટેડ ઝોન વાપરે છે જેને તમે ઇરાદાપૂર્વક ઓફિસથી રિઝોલ્વ કરી શકાય તેવો બનાવ્યો છે.

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

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

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

પહોંચવું એ અધિકૃતિ નથી

એન્ડપોઇન્ટ સુધી પહોંચતી વિનંતીને હજી પણ અધિકૃત પ્રિન્સિપાલ અને લાગુ પડતી બકેટ પરવાનગી જોઈએ. એન્ડપોઇન્ટ નીતિ એન્ડપોઇન્ટ શું મંજૂરી આપે છે તે સંકુચિત કરી શકે છે, અને બકેટ નીતિ તેને ફરી સંકુચિત કરી શકે છે. ઇન્ટરફેસ સુધી પહોંચવું એ વિશે કંઈ કહેતું નથી કે કૉલર કઈ વસ્તુઓ વાંચી શકે છે.

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

છેલ્લે, ફાળવણી કરતા પહેલાં બંને વિકલ્પોની કિંમત જુઓ. ઇન્ટરફેસ એન્ડપોઇન્ટ ઇન્ટરફેસ-કલાક અને ગીગાબાઇટ દીઠ બિલ કરે છે, જ્યારે ગેટવે એન્ડપોઇન્ટ નહીં, અને એ જ તફાવત ઘણા ઓછા-વોલ્યુમ વર્કલોડ માટે પ્રશ્ન નક્કી કરે છે જેમને ફક્ત VPC-બાજુની ઍક્સેસ જોઈએ છે.