EC2 ხელმისაწვდომობის ზონებში: შეამოწმეთ მარშრუტიზაცია VPN-მდე

სანამ ორ EC2 ინსტანსს შორის VPN პროგრამულ უზრუნველყოფას დააყენებთ, უპასუხეთ ერთ კითხვას: იმყოფებიან ისინი ერთ VPC-ში? თუ ასეა, კერძო გზა უკვე არსებობს და ზონებს შორის განლაგება ამას არ ცვლის. ამ სიტუაციაში სამუშაოს უმეტესი ნაწილია იმის დადასტურება, თუ რომელ მარშრუტიზაციის ცხრილს იყენებს რეალურად თითოეული ქვექსელი, და შემდეგ იმის გარკვევა, იყო თუ არა ხარვეზი საერთოდ მარშრუტიზაციის პრობლემა. გვირაბი, როგორც წესი, არასწორი პასუხია ამ კონკრეტულ კითხვაზე.

შემოწმება 1: იგივე VPC თუ სხვადასხვა VPC

VPC რეგიონულია და მოიცავს ხელმისაწვდომობის ზონებს, ხოლო თითოეული ქვექსელი ეკუთვნის ზუსტად ერთ ზონას. ერთი VPC-ის სხვადასხვა ზონაში მყოფი ორი ინსტანსი მაინც იმავე კერძო მარშრუტიზაციის დომენშია.

სხვადასხვა VPC არასოდეს იღებს კერძო მარშრუტს მხოლოდ იმიტომ, რომ ისინი იზიარებენ რეგიონს ან ზონის ჭდეს. ეს შემთხვევა მოითხოვს მხარდაჭერილ კავშირს და საკუთარ სამუშაოს მარშრუტებსა და ნებართვებზე, რაც ცალკე გადაწყვეტილებაა.

შემოწმება 2: რას ამბობს ქვექსელების მარშრუტიზაციის ცხრილები

ჩამოწერეთ განლაგება რეალური მნიშვნელობებით. VPC მისამართზე 10.60.0.0/16 ქვექსელებით 10.60.1.0/24 და 10.60.2.0/24 ინსტანსებს 10.60.1.10 და 10.60.2.20 აძლევს გზას VPC-ის ლოკალური მარშრუტის გავლით.

შემდეგ შეამოწმეთ ორივე ქვექსელთან დაკავშირებული ცხრილები და არა მხოლოდ ის, რომელიც პირველად იპოვეთ. უფრო კონკრეტულმა შემოწმების ან მოწყობილობის მარშრუტმა შეიძლება გადაფაროს საბაზისო მარშრუტი, და ლოკალური მარშრუტის სამიზნე თავად შეიძლება შეიცვალოს უფრო ახალ კონფიგურაციებში. კონსოლში სადმე ხილული ლოკალური მარშრუტი არ ამტკიცებს, რომ ორივე დატვირთვა მას იყენებს.

გამოიყენეთ ის კერძო მისამართები და სახელები, რომლებსაც VPC რეალურად ანიჭებს. კერძო მისამართი სულაც არ უნდა იწყებოდეს 10-ით, და მეხსიერებიდან მისამართის გამოგონება სწორედ ის გზაა, რომლითაც მუშა გარემოს არასწორ დიაგნოზს უსვამენ.

შემოწმება 3: მარშრუტიზაცია თუ ავტორიზაცია

მარშრუტიზაცია პაკეტს მხოლოდ სამიზნის ქსელურ ინტერფეისამდე აღწევს. სამიზნის უსაფრთხოების ჯგუფმა კვლავ უნდა დაუშვას წყარო და სერვისი, წყაროს გამავალი წესები უნდა დაუშვას მოთხოვნა, და ნებისმიერმა ქსელურმა ACL-მა უნდა დაუშვას ორივე მიმართულება, რადგან ACL-ები მდგომარეობას არ ინახავენ.

ამის მიღმაა სტუმრის ფაირვოლი, მსმენელის მიბმა და თავად აპლიკაციის იდენტობა. თითოეულ მათგანს შეუძლია უარყოს მოთხოვნა, რომელიც მარშრუტიზაციამ სრულყოფილად მიიტანა.

მიღება უნდა იყოს აპლიკაციის რეალური ოპერაცია. წარმატებული ping არ იძლევა აპლიკაციაზე წვდომას და არ ამტკიცებს, რომ TLS სახელი და რწმუნებები სწორია, ხოლო დაბლოკილი ping არ ადგენს, რომ ყველა კერძო სერვისი გამორთულია.

შემოწმება 4: მართლა საჭიროა ცალკე კავშირი

VPN შეიძლება კვლავ იყოს დიზაინში, მაგრამ მითითებული მიზეზით: ამ VPC-ის ოფისთან დაკავშირება, ლეპტოპების დაშვება ან გადაფარვის მოთხოვნის დაკმაყოფილება. ეს მიზეზი განსხვავდება იმავე VPC-ში ჩვეულებრივი კომუნიკაციისგან.

გაიხსენეთ ასევე, რაც VPC არ არის. ის არ არის სახლის Ethernet სეგმენტის გაფართოება. აპლიკაციას, რომელიც დამოკიდებულია მაუწყებლობით აღმოჩენაზე, აქვს ცალკე შესაფასებელი მოთხოვნა. ეს დიზაინის ხარვეზია და არა მარშრუტიზაციის შეცდომა.

შემოწმება 5: დაშიფვრის საკითხი

კერძო მისამართი და ნებართვის წესი არაფერს ამბობს აპლიკაციის დონეზე კრიპტოგრაფიულ დაცვაზე. თუ მონაცემებს სჭირდება დაცვა ბოლოდან ბოლომდე, ის მოდის იმ პროტოკოლიდან და იდენტობის მოდელიდან, რომელსაც სერვისი რეალურად მხარს უჭერს.

დიზაინის ჩანაწერში ქსელური და აპლიკაციური დონის მტკიცებები ცალ-ცალკე შეინახეთ, რადგან მათი შერწყმა სწორედ ის გზაა, რომლითაც მიმოხილვა საბოლოოდ ამტკიცებს დაცვას, რომელიც არავის დაუნერგავს.

რა უნდა ჩაიწეროს

ჩაწერეთ ორივე ქვექსელის იდენტიფიკატორი, თითოეულთან დაკავშირებული მარშრუტიზაციის ცხრილი, უსაფრთხოების ჯგუფების მითითებები და აპლიკაციის ოპერაცია, რომელიც გამოსცადეთ. ეს ოთხი ფაქტია და ისინი წყვეტს ამ გზის შესახებ მომავალი კამათის უმეტესობას.

მხოლოდ ზონაში განლაგება არასოდეს გეუბნებათ, რომ დაამატოთ VPN, და არასოდეს ხსნის, რატომ ჩავარდა კერძო მოთხოვნა.