strongSwan EC2-ზე: დაე VPC-მ სამუშაო დატვირთვა დაამარშრუტოს

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

ჯერ ჩაწერეთ ოთხი მისამართი

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

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

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

ნაბიჯი 1: მიეცით სამუშაო დატვირთვის ქვექსელს მარშრუტი

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

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

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

ნაბიჯი 2: ჩართეთ გადაცემა სტუმარზე

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

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

ნაბიჯი 3: გააფართოვეთ სელექტორები რეალურ წყაროებამდე

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

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

თუ შეთანხმებული დიზაინი მთელ VPC-ს იცავს, ორივე მხარემ უნდა მიიღოს 10.60.0.0/16 და 10.90.0.0/24. თუ ის ერთ სამუშაო დატვირთვას იცავს, განზრახ გამოიყენეთ ის უფრო ვიწრო პრეფიქსი. ნებისმიერ შემთხვევაში, შეამოწმეთ დაყენებული CHILD-SA პოლიტიკა, რადგან თქვენ მიერ რედაქტირებული კონფიგურაცია და მეორე მხარე, რომელმაც ის სხვაგვარად შევიწროვა, ერთი და იგივე შეთანხმება არ არის.

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

ნაბიჯი 4: შეამოწმეთ და საჭიროების შემთხვევაში უკან დააბრუნეთ

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

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

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