AWS Client VPN: შესვლა წარმატებულია, მაგრამ ქვექსელში მოხვედრა შეუძლებელია
AWS Client VPN-ში წარმატებული შესვლა ყველა ქვექსელის ავტორიზაციას არ ნიშნავს. წვდომის გაფართოებამდე შეამოწმეთ ჯგუფის მნიშვნელობა და ყველაზე კონკრეტული დანიშნულების წესი.
თქვენი კლიენტი აჩვენებს Connected-ს, სერტიფიკატი ვალიდურია, და ინტრანეტის გვერდი მაინც დროის ამოწურვით სრულდება. ეს სხვაობა თითქმის არასოდეს არის ავთენტიფიკაცია. AWS Client VPN დანიშნულებებს შესვლისგან ცალკე ავტორიზებს და ჩვეულებრივი ორი მიზეზია: ჯგუფის მნიშვნელობა, რომელიც არ ემთხვევა პირადობის პროვაიდერის გამოგზავნილს, და უფრო კონკრეტული დანიშნულების წესი, რომელიც ფართო წესს სძლევს. ორივე endpoint-ის კონფიგურაციაში ჩანს, როცა იცი სად უნდა შეხედო.
შესვლა შედგა; წესი არ დაემთხვა
ავთენტიფიკაცია პასუხობს, ვინ არის მომხმარებელი. ავტორიზაციის წესები პასუხობს, რომელ ქსელურ პრეფიქსებზე შეიძლება ამ პირადობის მიღწევა. მომხმარებელმა შეიძლება პირველი გაიაროს და მეორეზე ჩავარდეს, ხოლო კლიენტი გაძლევთ მხოლოდ კავშირს, რომელიც ღიად რჩება, სანამ ყოველი მოთხოვნა დროის ამოწურვით სრულდება.
დაიწყეთ იმის დადასტურებით, რომ endpoint-ს აქვს ავტორიზაციის წესი, რომლის დანიშნულება შეიცავს წარუმატებელ მისამართს. თუ შესაბამისი წესი არ არსებობს, კავშირი სწორად იქცევა; პოლიტიკა აკლია.
საიდან მოდის სინამდვილეში ჯგუფის მნიშვნელობა
Active Directory-ში access-group ველი ინახავს ჯგუფის SID-ს და არა მის ჩვენების სახელს. SAML ფედერაციაში ის ინახავს იმ ჯგუფის ID-ს ან სახელს, რომელსაც კონფიგურირებული SAML ჯგუფის ატრიბუტი რეალურად ატარებს. დააკოპირეთ მნიშვნელობა assertion-იდან ან დირექტორიის ძიებიდან, და არა ვიკი გვერდიდან.
IAM ჯგუფი სხვა მართვის სიბრტყეა. Client VPN endpoint-ის ადმინისტრირების ნებართვა IAM ჯგუფს მომხმარებლის VPN ჯგუფად არ აქცევს, და IAM ჯგუფის სახელის access-group ველში ჩასმა მას AD SID-ად ან SAML ატრიბუტის მნიშვნელობად არ გარდაქმნის.
სხვა დირექტორიაში მსგავსი სახელის ჯგუფი არაფერს ამტკიცებს. შეამოწმეთ endpoint-ის ავთენტიფიკაციის მეთოდი და მომხმარებლის წევრობა ან assertion იმავე სისტემაში.
ყველაზე გრძელი პრეფიქსი იმარჯვებს, მათ შორის 0.0.0.0/0
ავტორიზაცია ფასდება ყველაზე გრძელი პრეფიქსის დამთხვევით, და ყველა დანიშნულების წესი პირველად კი არა, ბოლოს ფასდება. დაამატეთ 10.46.0.0/16 წესი Engineering-ისთვის და 0.0.0.0/0 წესი ყველასთვის, და Engineering-ის გარეთ მყოფი მომხმარებელი მაინც ვერ მიაღწევს 10.46.20.10-ს ფართო წესით.
სწორედ აქ შეიძლება გასწორება არასწორად წავიდეს. ვიწრო წესის წაშლა აღადგენს მომხმარებლის წვდომას და ამავე დროს ამ ქვექსელს ფართო წესით დაფარულ ყველა პირადობას აძლევს. ააგეთ ჯგუფ-ქსელის მატრიცა, სანამ რამეს წაშლით, და ჩაწერეთ, რომელმა ჯგუფმა რომელ დიაპაზონს უნდა მიაღწიოს. ეს წესები მხოლოდ ნებას რთავს; ფართო ნებართვიდან გამონაკლისის ამოჭრის აკრძალვის ჩანაწერი არ არსებობს.
ცვლილებებს სამართლიანი შეფასებისთვის ახალი კავშირიც სჭირდება. წესების რედაქტირების შემდეგ ხელახლა დაუკავშირეთ კლიენტი, შემდეგ კვლავ გამოსცადეთ.
გამოყავით ავტორიზაცია მონაცემთა გზისგან
დამთხვეული წესი მარშრუტი არ არის. endpoint-ს სჭირდება დაკავშირებული ქვექსელი და მარშრუტიზაციის ცხრილის ჩანაწერი დანიშნულებისთვის, ხოლო სამიზნე რესურსის უსაფრთხოების ჯგუფმა ტრაფიკი უნდა მიიღოს. დაბრუნებული ტრაფიკი და DNS-იც უნდა მუშაობდეს.
გამოსცადეთ მომხმარებელი, რომელიც უნდა წარმატდეს, და მომხმარებელი, რომელიც გარეთ უნდა დარჩეს. ორივეს შეუძლია შესვლა, მაგრამ მხოლოდ ერთი აღწევს ქვექსელს, და ეს განსხვავებაა სასურველი მტკიცებულება.
თუ IP მისამართი მუშაობს, ხოლო ჰოსტის სახელი არა, ავტორიზაციაზე ხელის დაჭერამდე შეხედეთ resolver-ს. თუ არც ერთი მარშრუტი არ ფარავს მისამართს, გაასწორეთ კავშირი ან მარშრუტიზაციის ცხრილი. თუ პაკეტი მოდის და სერვისი უარყოფს მას, შემდეგი გაჩერება ამ სერვისის პოლიტიკაა. ავტორიზაციის მატრიცის ყველა მომხმარებელზე გაფართოება მალავს, რომელი ფენა იყო რეალურად გატეხილი.
ბილეთის დახურვამდე ჩაწერეთ პირადობის წყარო, ჯგუფის ზუსტი მნიშვნელობა, დანიშნულების პრეფიქსები და მარშრუტი, რომელიც ტრაფიკს ატარებს. ეს ჩანაწერი შემდეგ ცნობას დაკავშირებულია, მაგრამ წვდომა არ არის აქცევს ორწუთიან შედარებად, და არა კიდევ ერთ ვარაუდების რაუნდად.