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-ის მხრიდან წვდომა სჭირდებათ.