S3 դարպաս կամ ինտերֆեյսի վերջնակետ՝ տեղական ցանցի հաճախորդի համար

S3-ին հասնելը գրասենյակային ցանցից site VPN-ով երթուղային խնդիր չէ, որը ստատիկ երթուղին ինքնուրույն կարող է լուծել։ Դարպասի վերջնակետը կցվում է երթուղային աղյուսակներին և սպասարկում է 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-ի կողմից հասանելիություն են պահանջում։