AWS Client VPN თუ bastion peered VPC-მდე მისასვლელად
ორივე გზა მუშაობს, მაგრამ სხვადასხვა ადგილას ტყდება. შეადარეთ endpoint მარშრუტები, დაბრუნების მარშრუტიზაცია და სამი შემთხვევა, როცა bastion პატიოსანი საზღვარია.
ერთ Client VPN endpoint-ს შეუძლია მიაღწიოს VPC-ს, რომელიც peering-ით არის დაკავშირებული მის ასოცირებულ VPC-სთან, და ამის ლეგიტიმურად გასაკეთებლად bastion არ გჭირდებათ. არჩევანი, რომლის გაკეთებაც ღირს, არის ის, სად იცვლის ტრაფიკი ხელს: endpoint მარშრუტი, რომელიც association ქვექსელში ეშვება და კვეთს peering კავშირს, ან host peered VPC-ში, რომელიც სესიას ამთავრებს. ორივე გზა მუშაობს და სხვადასხვა ადგილას ფეილდება, ამიტომ გადაწყვეტილება საკუთრებასა და აუდიტზეა, არა იმაზე, თუ რას უშვებს AWS. აქ არის, როგორ ვარჩევ მათ შორის, და ის ოთხი ჩანაწერი, რომლებიც მარშრუტიზებულ გზას ამუშავებს.
ორი გზა, ერთი endpoint, სხვადასხვა მფლობელი
მარშრუტიზებულ გზაზე კლიენტის ტრაფიკი endpoint-ს აღწევს, association ქვექსელში Client VPN ქსელური ინტერფეისის მისამართად ითარგმნება და ამ ქვექსელს ტოვებს A-დან B-მდე peering კავშირით. VPC B არ ამთავრებს არცერთ VPN სესიას; ის VPC A-დან ჩვეულებრივ ტრაფიკს ხედავს, ამიტომ მისი დაბრუნების მარშრუტი VPC A-ზე მიუთითებს და არა კლიენტთა პულზე.
bastion გზაზე კლიენტი ჯერ host-ს აღწევს. bastion A-ში ჯერ კიდევ ტოვებს ბოლო ნახტომს peering კავშირის გავლით, ასე რომ ინარჩუნებთ peering სამუშაოს და ამატებთ სესიას. bastion B-შიც საჭიროებს გზას კლიენტიდან, და როცა ეს გზა იგივე endpoint მარშრუტია, გაქვთ მარშრუტიზებული დიზაინი პლუს ერთი ნახტომი. bastion სამუშაოს მხოლოდ მაშინ აკლებს, როცა ის უკვე არსებობს, უკვე დამტკიცებულია, და მის უკან არსებულს ქსელური საზღვრის ნაცვლად სესიის საზღვარი სჭირდება.
ოთხი ჩანაწერი მარშრუტიზებულ გზას ამუშავებს
AWS ამ სცენარს Client VPN how-it-works გვერდზე აღწერს, და პრაქტიკაში ყველაფერი ოთხ ჩანაწერამდე მოდის, რომლებსაც ორი ან სამი გუნდი ფლობს. დიაპაზონები საილუსტრაციოა; peered დიაპაზონი უნდა იყოს უნიკალური, ხოლო დაბრუნების დიაპაზონი უნდა შეესაბამებოდეს თქვენს გეგმას.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
მარშრუტი და ნებართვა ცალკე კონტროლია. სწორი endpoint მარშრუტი შესაბამისი ავტორიზაციის წესის გარეშე კლიენტს არაფერს აძლევს; ავტორიზაციის წესი იმ დანიშნულებისთვის, რომელსაც endpoint ვერ მარშრუტიზაციას უკეთებს, მას შავ ხვრელს აძლევს. ორივემ ერთი და იგივე დიაპაზონი უნდა დაასახელოს.
endpoint მარშრუტი endpoint-ის საკუთარ VPC-ში არსებულ ქვექსელზე მიუთითებს, არასდროს peering კავშირზე. VPC მარშრუტების ცხრილები peering კავშირზე მიუთითებს, არასდროს instance-ზე ან ინტერფეისზე. მნიშვნელობის კოპირება მათ შორის უჩივლელად ინახება და არაფერს მარშრუტიზაციას უკეთებს.
რადგან association ქვექსელი კლიენტის წყაროს თარგმნის, B-მ უნდა დააბრუნოს მარშრუტი VPC A-ზე და არა კლიენტთა პულზე. კლიენტის დიაპაზონის peering კავშირზე გაგზავნა სიმეტრიულად გამოიყურება, გადის განხილვას და ჩუმად ფეილდება, რადგან B არასდროს ხედავს პაკეტს კლიენტის წყაროთი.
უსაფრთხოების ჯგუფები და ნებართვის ბოლო მეტრი
მარშრუტიზაცია პაკეტებს B-ში შეიტანს; B მაინც წყვეტს. იმავე რეგიონში აქტიური peering კავშირისთვის B-ში უსაფრთხოების ჯგუფს შეუძლია მიუთითოს Client VPN association-ზე გამოყენებულ ჯგუფზე, რაც წესს ვიწროდ ინახავს და მისამართების ცვლილებებს უძლებს. სადაც ჯგუფზე მითითება შეუძლებელია, ნება დართეთ association ქვექსელის დიაპაზონს ცალსახად, ნაცვლად 0.0.0.0/0-მდე გაფართოებისა, რაც მარშრუტიზაციის შეცდომას აუხსნელ timeout-ად აქცევს.
შემდეგ შეამოწმეთ ის, რასაც მარშრუტიზაცია არასდროს ეხება: ქსელური ACL-ები ორივე ქვექსელში, აპლიკაციის დაშვებულთა სია ან token-ის აუდიტორია, და DNS. peering არ აკოპირებს კერძო ჰოსტინგის ზონებს, ამიტომ ლეპტოპს შეიძლება ჰქონდეს მოქმედი მარშრუტი იმ მისამართზე, რომლის ამოხსნასაც ვერ ახერხებს, და peering კავშირი სერტიფიკატს ნდობას არ მატებს. მიმართეთ endpoint resolver-ზე, რომელიც B-ისთვის პასუხობს, შემდეგ დაადასტურეთ, რომ კერძო სახელი და სერტიფიკატი ემთხვევა.
როცა bastion პატიოსანი პასუხია
სამ ტრიგერს ვინახავ bastion-ის განზრახ ასარჩევად. peered VPC ეკუთვნის გუნდს, რომელიც თქვენი დიაპაზონისთვის დაბრუნების მარშრუტს არ დაამატებს ან ჯგუფზე მითითებას არ მიიღებს. წვდომა უნდა დამტკიცდეს ან ჩაიწეროს ყოველი სესიისთვის და აპლიკაცია ამას თავად ვერ ატარებს. ან ბოლო ნახტომი უნდა დარჩეს B-ის შიგნით, რადგან სერვისი მხოლოდ იქ ამოიხსნება და მისი TLS იდენტობა შიდა სახელზეა მიმაგრებული.
ამათგან არცერთი არ არის გვერდის ავლა იმ ფაქტისა, რომ peering ტრანზიტული არ არის. არატრანზიტულობა ზღუდავს, რისი გაკეთებაც B-ის რესურსებს შეუძლიათ: მათ არ შეუძლიათ A-ს გამოყენება ტრანზიტად მესამე VPC-ში, რომელთანაც A peering-შია. ეს არასდროს ნიშნავდა, რომ VPN მომხმარებელი ვერ მიაღწევს პირდაპირ peered VPC-ს, და ამ არასწორი წაკითხვის ასარიდებლად აშენებული bastion host-ია, რომელიც ტყუილად patch-დება.
საპირისპირო შეცდომა დროთა განმავლობაში უფრო ძვირია: გაატარეთ ყოველი გუნდი უკვე არსებულ ერთადერთ bastion-ზე, შემდეგ აღმოაჩინეთ, რომ მისი უსაფრთხოების ჯგუფი, მარშრუტების ცხრილი და patch-ის ფანჯარა წარმოების დამოკიდებულებაა. ჩაწერეთ, რომელ ტრიგერს ემსახურება host, და გაიყვანეთ იგი ექსპლუატაციიდან, როცა ტრიგერი გაქრება.
Transit Gateway და რამდენიმე association ცვლის არითმეტიკას
თუ endpoint პირდაპირ Transit Gateway-ზეა მიმაგრებული და არა ქვექსელზე, მოდელი იცვლება: კლიენტები აღარ ითარგმნებიან association ქვექსელის ინტერფეისის მისამართად, და gateway-ის მარშრუტების ცხრილებმა უნდა ატარონ კლიენტის დიაპაზონი პლუს მიმაგრება, რომელიც peered VPC-მდე მიდის. მასშტაბში ეს უფრო სუფთაა, მაგრამ სამუშაო ოთხი ჩანაწერიდან gateway-ის მარშრუტების ცხრილებში გადადის.
რამდენიმე association ამრავლებს შემოწმებებს. endpoint მარშრუტი endpoint-ისაა, თუმცა ყოველ association ქვექსელს სჭირდება მარშრუტების ცხრილი ნამდვილი peering შემდეგი ნახტომით. სესია შეიძლება წარმატებული იყოს ერთი association-ით, სანამ მეორეს დაბრუნების გზა არ აქვს, ამიტომ გამოსცადეთ თითოეული.
შემოწმების თანმიმდევრობა, რომელიც ჩავარდნას სწრაფად პოულობს
შეასრულეთ ესენი თანმიმდევრობით; ყოველი ნაბიჯი შეიძლება გაიაროს, სანამ შემდეგი ფეილდება, და კლიენტის timeout თითქმის არასდროს ამბობს, რომელი გატყდა.
- ამოხსენით აპლიკაციის სახელი კლიენტიდან და შეამოწმეთ, რომ მისამართი peered დიაპაზონშია.
- დაუკავშირდით, შემდეგ წაიკითხეთ endpoint-ის კავშირების ჟურნალი იმ association-ისთვის, რომელმაც სესია დაასრულა.
- ამ association ქვექსელზე დაადასტურეთ, რომ მარშრუტების ცხრილი peered დიაპაზონს აქტიურ peering კავშირზე მიმართავს.
- B-ის რესურსების ქვექსელზე დაადასტურეთ ინტერფეისის დიაპაზონის დაბრუნების ჩანაწერი და შესაბამისი ჯგუფის წესები.
- გამოსცადეთ ერთი დაშვებული ოპერაცია და ერთი რესურსი, რომელიც მიუწვდომელი უნდა დარჩეს; მეორე დებაგინგის ნარჩენებს იჭერს.
- ხელახლა დაუკავშირდით split-tunnel მარშრუტის ნებისმიერი ცვლილების შემდეგ, რადგან მოქმედი გვირაბი ახალ მარშრუტთა ნაკრებს არ აიღებს.
ორი სიმპტომი დასამახსოვრებელია. B-მდე უპასუხოდ მისული SYN თითქმის ყოველთვის დაკარგული დაბრუნების მარშრუტია. დასრულებული და შემდეგ გადატვირთული კავშირი ჩვეულებრივ ჯგუფია, ACL ან აპლიკაცია. არცერთი არ ჩანს endpoint-ის ჟურნალში მიზეზად, ამიტომ შეინახეთ ოთხი ჩანაწერი თითოეულის გვერდით მფლობელით.
თუ სამი ტრიგერიდან არცერთი არ მოქმედებს, დაასრულეთ მარშრუტიზებული გზა და ჩაწერეთ ეს ოთხი ჩანაწერი. თუ ერთი მოქმედებს, შეინახეთ bastion მხოლოდ ამ საზღვრისთვის და დატოვეთ endpoint მარშრუტი იმ სერვისებს, რომლებსაც წინ სესია არ სჭირდებათ.