რატომ ვერ აღწევს EC2 თქვენს AWS Client VPN ლეპტოპამდე
Client VPN IPv4 კლიენტის წყაროებს ბოლო წერტილის ინტერფეისში გარდაქმნის. ამიტომ პასუხი მუშაობს, ხოლო EC2-დან ახალი კავშირი არა.
AWS Client VPN-ით დაკავშირებული ლეპტოპი EC2-ის აპლიკაციას უპრობლემოდ აღწევს. შემდეგ ცდილობთ საპირისპიროს, EC2-დან კლიენტისთვის მინიჭებულ მისამართამდე, და კავშირი იკიდება ან უარყოფილ იქნება. ეს ასიმეტრია იშვიათად არის უსაფრთხოების ჯგუფის დაკარგული წესი. VPC ქვექსელებთან დაკავშირებულ Client VPN ბოლო წერტილზე AWS IPv4 კლიენტის წყაროებს ბოლო წერტილის ქსელურ ინტერფეისში გარდაქმნის, ამიტომ არ არსებობს შემომავალი VPC მისამართი, რომელიც თქვენს ლეპტოპს წარმოადგენს.
დაიწყეთ იმით, რასაც ჩანაწერი აჩვენებს
გააკეთეთ ჩანაწერი EC2 ჰოსტზე, სანამ კლიენტი უკავშირდება, და წაიკითხეთ წყარო მისამართი, რომელსაც აპლიკაცია რეალურად ხედავს. თუ ეს VPC-ის მხარეს ბოლო წერტილის ინტერფეისია და არა კლიენტთა აუზიდან მისამართი, გარდაქმნა დადასტურებულია სანამ ერთ წესსაც კი შეცვლით.
კლიენტთა აუზი გამოყოფის დიაპაზონია და არა ქვექსელი დაბრუნების მარშრუტით. სწორედ ამ განსხვავებაზე ცდება ასეთი გამოძიებების უმეტესობა.
გარდაქმნა, რომელიც ასიმეტრიას ხსნის
სამი ნაკადი ერთმანეთში ირევა და მათგან მხოლოდ ერთია ის, რასაც ხალხი ამოწმებს.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN კომპონენტების აღწერა ცხადად ამბობს, რომ IPv4 კლიენტის წყაროები ბოლო წერტილის ინტერფეისში გარდაიქმნება, და ეს საკმარისია იმის სანახავად, თუ რატომ არ აქვს შუა რიგს შესადარებელი არაფერი.
ახალ კავშირს სჭირდება მარშრუტი, მისამართის გარჩევის ნაბიჯი და ავტორიზაციის გადაწყვეტილება. სხვისი სესიიდან მიღებული გარდაქმნის მდგომარეობა ამ სამიდან არცერთს არ იძლევა.
რატომ არ არის პასუხი ახალი კავშირი
TCP პასუხი არსებულ ჩანაწერს ემთხვევა, ამიტომ დაბრუნების გზა საერთოდ შემომავალი წესის გარეშე მუშაობს. EC2 ჰოსტიდან ახალ SYN-ს შესადარებელი ჩანაწერი არ აქვს, ამიტომ ის ჩვეულებრივ გამავალ მცდელობად იქცევა იმ დანიშნულებისკენ, სადამდე მისვლა VPC-მ არ იცის.
ამიტომაც შეცდომაა ამის აღწერა მხოლოდ ერთი მიმართულებით მავალ ტრაფიკად. ამ სესიებში დაბრუნების ტრაფიკი განუწყვეტლივ მიედინება. გზის გარეშე დარჩენილი ნაწილი დაწყებაა.
რა არღვევს კვლავ სესიას, რომელიც უნდა მუშაობდეს
უსაფრთხოების ჯგუფები, ქსელური ACL-ები და თავად ლეპტოპის firewall — ყველა მნიშვნელოვანია იმ კავშირებისთვის, რომლებიც უნდა წარმატდეს. წარუმატებელი ping ყველაზე ნაკლებს გვეუბნება, რადგან ICMP პოლიტიკა ხშირად განცალკევებულია იმ TCP პოლიტიკისგან, რომელიც გაინტერესებთ.
დაწერეთ ეს წესები გარდაქმნილი წყაროს მიხედვით და არა კლიენტის მისამართის. ქსელში არასდროს გამოჩენილ მისამართზე მიბმული წესები ამ დიზაინში ყველაზე გავრცელებული თვითგამოწვეული ხარვეზია.
როცა VPC-მ ნამდვილად უნდა დაიწყოს საუბარი
თუ სერვისმა სამუშაო სადგურს უნდა აცნობოს, გადაატრიალეთ მიმართულება და მისცეთ კლიენტს მუდმივი გამავალი არხის შენარჩუნების საშუალება, რომელზეც სერვისი პასუხობს. თუ მთელი დისტანციური ქსელი VPC-დან უნდა იყოს მისაწვდომი, აირჩიეთ არქიტექტურა, რომელიც თავის პრეფიქსებსა და წვდომის პოლიტიკას აქვეყნებს იმის ნაცვლად, რომ ჩათვალოთ, თითქოს Client VPN უკვე აკეთებს ამას. კლიენტ-კლიენტ წვდომა მესამე, ვიწრო შემთხვევაა საკუთარი მარშრუტისა და ავტორიზაციის ობიექტებით. არცერთი ეს არ არის უბრალოდ მონიშვნის უჯრა არსებულ ბოლო წერტილზე.
IPv4-ის განმარტების ფარგლებიც პატიოსნად შეინარჩუნეთ. AWS-ის მიმდინარე დოკუმენტაცია გამოჰყოფს IPv6-ს, სადაც ეს გარდაქმნა არ გამოიყენება, და სხვა მიერთების მოდელებს, რომლებიც სხვაგვარად მარშრუტიზაციას აკეთებენ.
შეამოწმეთ სამ ეტიკეტირებულ ნაბიჯში: კლიენტი ხსნის ნებადართულ სესიას, VPC სერვისი პასუხობს ამ სესიას და VPC ჰოსტი ხსნის ახალ სესიას კლიენტისკენ. პირველი ორის წარმატება და მესამის წარუმატებლობა ამ დიზაინის მოსალოდნელი ფორმაა და არა ხარვეზი, რომლის მიღმაც firewall წესებით უნდა გავიქცეთ.