VGW თუ TGW? სად მთავრდება AWS Site-to-Site-ის IPsec გვირაბი

ადამიანები კითხულობენ, სად წყვეტს AWS Site-to-Site VPN პაკეტის დაცვას და ერთ პასუხს ელოდებიან: კარიბჭესთან. ამ პასუხის სასარგებლო ვერსია ასახელებს, რომელი კარიბჭე, რადგან ვირტუალური კერძო კარიბჭე და ტრანზიტული კარიბჭე სხვადასხვა მოწყობაა სხვადასხვა მიმაგრების ობიექტით და რეცენზენტი, რომელიც არასწორს ვარაუდობს, დანარჩენ შეფასებას აშენებს დიაგრამაზე, რომელიც არ არსებობს. შეასრულეთ ქვემოთ მოცემული სამი შემოწმება თანმიმდევრობით. თითოეული ან ადასტურებს საზღვარს, ან გეუბნებათ, რომ წინა პასუხი სხვა რესურსს ეხებოდა.

დაასახელეთ სამი ბოლო წერტილი, სანამ რამეს შეაფასებთ

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

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

შემოწმება 1: რომელი კარიბჭე ამთავრებს გვირაბს სინამდვილეში

ორივე მოწყობა მხარდაჭერილია და Site-to-Site VPN-ის არქიტექტურის გზამკვლევი მათ გვერდიგვერდ აღწერს, ამიტომ ჰკითხეთ API-ს და არა დიაგრამას, რომელიც ხშირად ერთი წლისაა. ერთ კავშირზე მხოლოდ-წაკითხვის მოთხოვნა აბრუნებს VPN სამიზნის ველებს:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

განმასხვავებელია TransitGatewayId და არა VpnGatewayId. კავშირი, რომელშიც TransitGatewayId ცარიელია, მთავრდება დამოუკიდებელ ვირტუალურ კერძო კარიბჭეზე, ხოლო კავშირი, რომელშიც ეს ველი დაყენებულია, მთავრდება ტრანზიტული კარიბჭის VPN მიმაგრებაზე, და VpnGatewayId ამ შემთხვევაში მაინც შეიძლება იყოს შევსებული, რადგან მას შეუძლია დაასახელოს მიმაგრების მატარებელი კარიბჭე. ჯერ წაიკითხეთ TGW ველი, შემდეგ დაადასტურეთ მიმაგრების ტიპი მიმაგრებათა სიიდან და არა ველის სახელიდან, რადგან ამ ტრანზიტულ კარიბჭეზე VPC მიმაგრება არ არის VPN მიმაგრება. დანიშნულების ინსტანსის პოვნა დაკავშირებულ VPC-ში არაფერს გეუბნებათ იმის შესახებ, თუ რომელმა VPN მიმაგრებამ გადაიტანა პაკეტი.

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

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

შემოწმება 2: რას ატარებს ჯერ კიდევ შიდა პაკეტი

როგორც კი IPsec დასრულდება, AWS დეკაფსულირებულ პაკეტს გზავნის იმ მარშრუტით, რომელიც მას შეესაბამებოდა. ამ წერტილიდან ტრაფიკი ჩვეულებრივი VPC ტრაფიკია და VPN-ის დაცვა დასრულდა. ეს სერვისში ხარვეზი არ არის; ეს არის საზღვრის მნიშვნელობა და ჩამონათვალის პუნქტია ამის პირდაპირ თქმა, ნაცვლად იმისა, რომ ფრაზას "VPN დაშიფრულია" დავუშვათ შეცვალოს "მონაცემები დაშიფრულია ბოლოდან ბოლომდე".

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

ჩვეულებრივი გადამეტებული შესწორებაა დასკვნა, რომ კარიბჭის უკან ყველაფერი ღიაა. ასე არ არის. სერვისის ტრანსპორტი, საცავის დაშიფვრა და აპლიკაციის TLS ცალკე მექანიზმებია ცალკე პირობებით და თითოეული უნდა შეფასდეს საკუთარი პირობებით და არა VPN-ის ფორმიდან გამოტანილ იქნას. ნაკადის ჟურნალის ჩანაწერი, რომელიც ACCEPT-ს აჩვენებს, ამტკიცებს, რომ მარშრუტიზაცია მუშაობდა და კონფიდენციალურობაზე არაფერს ამბობს, რაც ზუსტად ის შეცდომაა, რომლის თავიდან ასაცილებლადაც ეს ჩამონათვალი არსებობს.

შემოწმება 3: რა ამთავრებს TLS-ს კარიბჭის უკან

მიჰყევით მსმენელს და არა მისამართს. თუ დატვირთვის გამანაწილებელი ან პროქსი ამთავრებს TLS-ს, თქვენი კლიენტის კავშირი იქ მთავრდება და პროქსი ხსნის მეორე კავშირს ბექენდთან, რომელიც შეიძლება იყოს ღია ტექსტი ან სხვა ნდობის ჯაჭვის TLS. კერძო IP მისამართი და შესაბამისი მარშრუტი არ არის მტკიცებულება ამ მეორე კავშირის შესახებ.

გამოსცადეთ ის ბოლო წერტილი, რომელიც ნამდვილად გაღელვებთ, VPC-ის შიგნიდან, იმ სახელით, რომელსაც აპლიკაცია იყენებს და არა IP-ით, რომელიც ერთხელ გადაწყვიტეთ:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

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

შედეგი ჩაწერეთ სეგმენტებად და არა განაჩენად

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

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

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