შეწყვეტილი წვდომა AWS Client VPN-ით: შეამოწმეთ ყოველი დაკავშირებული ქვექსელი
AWS Client VPN-ის ზოგი სესია აპის VPC-მდე აღწევს, ზოგი კი ვადის გასვლით სრულდება. ჯერ შეადარეთ ენდპოინტის მარშრუტები თითოეული ასოციაციის VPC მარშრუტების ცხრილს.
მომხმარებელი უკავშირდება, ხსნის შიდა აპს და პასუხს იღებს; კოლეგა იმავე ენდპოინტზე დროის ამოწურვას იღებს იმავე Wi-Fi-ში მყოფი იდენტური ლეპტოპიდან. ეს ნიმუში client VPN ენდპოინტის ნიშანია, რომელსაც ერთზე მეტი დაკავშირებული ქვექსელი აქვს და სადაც ბილიკები ეკვივალენტური არ არის. მე ამას კონსოლიდან გარეთ მივყვები, რადგან ორი ჩანართი წყვეტს, ღირს თუ არა დანარჩენი გამოძიება. კლიენტის კონფიგურაციაში ვერაფერი ხსნის ამას.
დაიწყეთ ენდპოინტიდან და ჩამოთვალეთ ასოციაციები
VPC კონსოლში გახსენით Client VPN endpoints, აირჩიეთ ენდპოინტი და წაიკითხეთ Associations ჩანართი. თითოეული ასოციაცია ქვექსელია ხელმისაწვდომობის ზონაში და კლიენტი ხვდება იმაზე, რომელსაც სერვისი კავშირის აგებისას აირჩევს. ჩაიწერეთ ქვექსელების ID-ები და მარშრუტების ცხრილი, რომელსაც თითოეული რეალურად იყენებს, რადგან ეს ორი სიაა ის შედარება, რომელსაც აპირებთ.
თუ ენდპოინტი მხოლოდ ერთ ასოციაციას აჩვენებს, ეს თეორია მცდარია და კლიენტი უფრო კარგი ეჭვმიტანილია.
შეადარეთ ენდპოინტის მარშრუტების ცხრილი ყოველ ასოციაციას
გახსენით Route table ჩანართი იმავე ენდპოინტზე. იქ თითოეულ დანიშნულების CIDR-ს აქვს სამიზნე და client VPN-ში სამიზნე ასოციაციაა და არა კარიბჭე. AWS მოითხოვს დანიშნულების ჩანაწერს ყოველი დაკავშირებული ქვექსელისთვის, ამიტომ მარშრუტი, რომელიც მხოლოდ ერთ მათგანს მიმართავს, წვდომას დამოკიდებულს ხდის იმაზე, სად დაეშვა სესია. შეამოწმეთ დანიშნულება, რომელიც ნამდვილად გაწუხებთ, შემდეგ მისი ავტორიზაციის წესი, რადგან მარშრუტი გზას იძლევა და წესი წყვეტს, ვის შეუძლია მისი გამოყენება.
მას შემდეგ რაც ორივე ფენას ცხრილში მოაქცევთ, ხარვეზის გამოტოვება ძნელია.
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
მეორე სტრიქონია მთელი ხარვეზი უმეტეს ტიკეტებში. ენდპოინტის მარშრუტი არსებობს, ამიტომ არავინ იხედება შემდგომ, და პაკეტი ერთი ნახტომის შემდეგ იღუპება VPC-ის შიგნით.
მიჰყევით ყოველ ქვექსელს მის ფაქტობრივ მარშრუტების ცხრილამდე
ქვექსელი, რომელსაც მარშრუტების ცხრილთან გამოკვეთილი ასოციაცია არ აქვს, VPC-ის მთავარ ცხრილს მემკვიდრეობით იღებს. წაიკითხეთ ცხრილი, რომელიც ნამდვილად ძალაშია, და არა ის, რომლის სახელიც სწორად გამოიყურება, და შეადარეთ დანიშნულება და სამიზნე და არა სტრიქონის იარლიყი.
AWS-ის შეწყვეტილი წვდომის გზამკვლევი ამას წარმოადგენს როგორც მარშრუტების დაფარვას ასოციაციების მასშტაბით, რაც სწორი მოდელია. ენდპოინტი პაკეტს ქვექსელამდე მიიყვანს და ამ ქვექსელის ცხრილმა მაინც უნდა იცოდეს, სად არის აპლიკაციის ქსელი.
შეასწორეთ დაკარგული სტრიქონი იმ ცხრილში, რომელიც მას ფლობს. მთელი მარშრუტების ცხრილის კოპირება მუშა ქვექსელიდან ასევე აკოპირებს ინტერნეტის, მოწყობილობისა და იზოლაციის არჩევანს, რომლებიც ამისთვის არასდროს ყოფილა განკუთვნილი, და ეს გაცვლა ჩვეულებრივ უარესია, ვიდრე თქვენი დაწყებული შეფერხება.
შეამოწმეთ ავტორიზაციის წესები, შემდეგ დაბრუნების გზა
ავტორიზაციის წესები დანიშნულებისა და ჯგუფის მიხედვითაა და მარშრუტებისგან დამოუკიდებლად ფასდება. დანიშნულება, რომელსაც ყველგან მარშრუტები აქვს, მაგრამ მომხმარებლის ჯგუფისთვის წესი არ აქვს, იქცევა როგორც შავი ხვრელი ჯანსაღი იერსახის მარშრუტების ცხრილით.
დაბრუნების გზა იგივე ყურადღებას იმსახურებს. peering კავშირს სჭირდება მარშრუტი აპლიკაციის VPC-ში კლიენტის CIDR-ისკენ, უსაფრთხოების ჯგუფის წესები, რომლებიც ტრაფიკს ორივე ბოლოში უშვებს, და ქსელური ACL-ები, რომლებიც მას არ ყრიან. ცალმხრივი წვდომადობა, როცა ping მუშაობს და TCP ხელის ჩამორთმევა არა, ჩვეულებრივ VPN-ზე კი არა, ACL-ზე ან უსაფრთხოების ჯგუფზე მიუთითებს.
თავად ენდპოინტის უსაფრთხოების ჯგუფები ასოციაციის ელასტიურ ქსელურ ინტერფეისებზეა, ამიტომ წესი, რომელიც აპლიკაციის პორტს კლიენტის CIDR-იდან უშვებს, ასოციაციას უნდა მიმაგრდეს და არა მხოლოდ ინსტანსს.
დაადასტურეთ ხელახალი დაკავშირებით და არა ერთი იღბლიანი მოთხოვნით
split tunnel-ის შემთხვევაში ენდპოინტის მარშრუტები იგზავნება კავშირის დამყარებისას, ამიტომ შეცვლილი მარშრუტების ნაკრები ვერასდროს აღწევს დაკავშირებულ კლიენტამდე. გათიშეთ და ხელახლა დაუკავშირდით მხარდაჭერილი კლიენტით, შემდეგ დაადასტურეთ, რომ ახალი მარშრუტები მოწყობილობაზეა.
დაბოლოს, დააკავშირეთ კავშირების ჟურნალი იმ მისამართთან, რომელიც კლიენტმა მიიღო, და გაიმეორეთ ტესტი საკმარისად, რომ ერთზე მეტ ასოციაციას მოხვდეთ. ერთი წარმატებული მოთხოვნა შესწორების შემდეგ ამტკიცებს, რომ ერთი ბილიკი მუშაობს, და ტიკეტი მეორეზე იყო.