მომხმარებლის VPN ჯგუფში დამატება თავისთავად წვდომას არ ანიჭებს
ჯგუფის წევრობა ერთი პირობაა და არა ნებართვა. დააკვირდით, რას დაემთხვა გეითვეი სინამდვილეში, წაიკითხეთ დაშვების ან უარყოფის ჩანაწერი და გამოსცადეთ ორივე შედეგი.
ანგარიში სწორ ჯგუფში ჩასვით, შესვლა წარმატებით დასრულდა, მაგრამ კავშირი მაინც უარყოფილია — ან უკავშირდება და არაფერ სასარგებლოს არ აღწევს. ჩვეულებრივი რეფლექსია მომხმარებლის კიდევ უფრო მეტ ჯგუფში დამატება, სანამ რამე არ დათმობს, და სწორედ ასე აღმოჩნდება ორგანიზაცია იმაზე გაცილებით მეტის მიმნიჭებელი, ვიდრე ბილეთი ითხოვდა. ჯგუფის წევრობა ავტორიზაციის გადაწყვეტილების ერთი შემავალია და არასდროს თავად გადაწყვეტილება: გეითვეი სესიის შესახებ რამდენიმე ფაქტს აგროვებს, ადარებს მათ დალაგებულ პოლიტიკას და მხოლოდ ამის შემდეგ წყვეტს, რას შეიძლება შეეხოს ეს სესია. თუ სხვა პირობა ჩავარდა, ჯგუფის რედაქტირება არაფერს ცვლის გარდა თქვენი ექსპოზიციისა. აი, როგორ იკრიბება გადაწყვეტილება სინამდვილეში, სად წყვეტს წევრობა საკმარისობას და რომელი შემოწმება გეტყვით, რომელ წარუმატებლობას უყურებთ.
ჯგუფის წევრობა პირობაა და არა ნებართვა
RADIUS-ში ჯგუფი მოდის ავტორიზაციის ატრიბუტის სახით, და ატრიბუტები სესიას აღწერენ და არა ანიჭებენ. სერვერი პასუხობს Access-Accept ან Access-Reject-ით; დაშვებისას მან შეიძლება მიამაგროს Filter-Id, Class ან RFC 2868-ის გვირაბის ატრიბუტები, და მეორე მხარეს არსებული ქსელური მოწყობილობა მათ ინტერპრეტირებს ისე, როგორც მისმა მწარმოებელმა გადაწყვიტა. პროტოკოლში არაფერი ასახავს ჯგუფს სრულ წვდომაზე. ეს ასახვა დაწერილია იმის მიერ, ვინც პოლიტიკა გეითვეიზე ან ქსელური წვდომის სერვერზე დააკონფიგურირა, და ის შეიძლება იყოს ისეთივე ვიწრო, როგორც ერთი ჰოსტი.
ამიტომ ერთი და იგივე ჯგუფის სახელი ორ სისტემაზე სხვადასხვაგვარად იქცევა. Microsoft NPS ქსელურ პოლიტიკებს პირობების, შეზღუდვებისა და პარამეტრებისგან აწყობს და აფასებს მათ დაკონფიგურირებული თანმიმდევრობით. OpenVPN Access Server-ს აქვს საკუთარი ჯგუფისა და წვდომის წესების მოდელი, ხოლო community OpenVPN სერვერი ხშირად მთელ ამ საკითხს client-connect სკრიპტს ან client-config-dir ფაილს გადასცემს. თითოეული ჯგუფს მოიხმარს; არცერთი არ იზიარებს სხვის უპირატესობის ლოგიკას. მათ შორის კოპირებული წესების ნაკრები არაფერს ამტკიცებს იმის შესახებ, რომელსაც თქვენ დებაგავთ.
წყვეტს დამთხვეული წესი და არა ჯგუფი, რომელსაც ელოდებოდით
ძრავების უმეტესობა ჩერდება პირველ დამთხვეულ პოლიტიკაზე, ან ყველაზე სპეციფიკურზე. თუ პოლიტიკა 3 უარყოფს და პოლიტიკა 7 უშვებს, სესია შეიძლება ჩავარდეს ისე, რომ იმ წესამდე საერთოდ არ მივიდეს, რომელიც გაატარებდა. თანმიმდევრობა რეალური პარამეტრია NPS-ზე და ქსელური წვდომის კონტროლის პროდუქტების უმეტესობაზე, და ის იცვლება, როცა პოლიტიკები წლების განმავლობაში ემატება. ვიღაც უარყოფის პოლიტიკას თავში აწევს უკავშირო ინციდენტის შესაკავებლად, და ჯგუფი, რომელიც გასულ კვარტალში მუშაობდა, წყვეტს მუშაობას.
ჯგუფთან ერთად მომავალი პირობები პრობლემის მეორე ნახევარია. მოწყობილობის მდგომარეობა, აუთენტიფიკაციის მეთოდი, MFA-ს დასრულება, წყარო ქსელი, სერტიფიკატის საგანი ან დღის დროის ფანჯარა — ყველა შეიძლება იჯდეს ერთსა და იმავე პოლიტიკაში. როცა ერთ-ერთი მათგანი არ სრულდება, პოლიტიკა არ ემთხვევა, ძრავა ქვემოთ გადადის და მოქმედებს ნაგულისხმევი უარყოფა. მომხმარებლის ადგილიდან ეს ჯგუფის უგულებელყოფას ჰგავს; ძრავის ადგილიდან ჯგუფი საერთოდ არ იკითხებოდა.
დირექტორიის დეტალები იმავე ილუზიას ქმნიან. პოლიტიკა, რომელიც Windows-ის ჯგუფის წევრობაზე ემთხვევა, კითხულობს SID-ებს მომხმარებლის ტოკენში, და იქ მხოლოდ უსაფრთხოების ჯგუფები ჩამოითვლება — გავრცელების ჯგუფი არასდროს ჩნდება. მომხმარებლის ძირითადი ჯგუფი საკუთარ ველშია და არა ჩამოთვლილ სიაში, ამიტომ ამ ჯგუფზე მიმაგრებული პოლიტიკა შეიძლება ჩუმად ჩავარდეს. გადარქმეული ჯგუფები და დომენთაშორისი SID-ები დამატებით გარდაქმნის საფეხურებს ქმნიან, რომლებიც ჩუმად ჩავარდება, როცა ნდობა ცალმხრივია.
წაიკითხეთ დაშვების ან უარყოფის ჩანაწერი, სანამ ჯგუფს შეეხებით
ჯერ ერთი კითხვა დასვით: მივიდა თუ არა მოთხოვნა საერთოდ ავტორიზაციის ეტაპამდე? NPS-ზე პასუხი უკვე ივენთ ლოგშია, სადაც 6272 აღრიცხავს მიცემულ წვდომას, 6273 — უარყოფას, ხოლო 6274 — მოთხოვნას, რომელიც სერვერმა პოლიტიკის შეფასებამდე გადააგდო. ეს სამი რიცხვი პრობლემას სამ სხვადასხვა გამოძიებად ყოფს და მხოლოდ ერთი მათგანი ჯგუფებს ეხება.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
როცა ლოგი მიუწვდომელია, დაკითხეთ სერვერი უშუალოდ და წაიკითხეთ, რას აბრუნებს. პასუხი, რომელსაც არც Filter-Id და არც გვირაბის ატრიბუტები არ მოჰყავს, გეუბნებათ, რომ სერვერი სესიას ჩვეულებრივად განიხილავს და გეითვეი საკუთარ წესებს იყენებს. პასუხი, რომელსაც ატრიბუტები მოჰყავს, მაგრამ აღსრულების წერტილი მათ არ ახორციელებს, სხვა ხარვეზია: ავტორიზაცია გავიდა და მოწყობილობამ, რომელსაც შედეგზე უნდა ემოქმედა, ის უგულებელყო.
radtest alice 'password' 10.0.0.5 0 testing123შეადარეთ დაბრუნებული ატრიბუტები მათ, რასაც გეითვეი ადოკუმენტირებს და არა იმას, რასაც ჯგუფის სახელი გვთავაზობს. ეს შედარება ჩვეულებრივ გამოყოფს პოლიტიკის პრობლემას აღსრულების პრობლემისგან მანამ, სანამ ვინმე ჯგუფს შეასწორებს.
ჯგუფის ცვლილება უკუძალას არ იძენს
ავტორიზაციის ატრიბუტები ერთხელ ბრუნდება, როცა სესია აუთენტიფიცირდება. გეითვეი მათ სესიაზე ინახავს და ყოველ პაკეტზე დირექტორიას ხელახლა არ კითხულობს, და სწორედ ამიტომ დამყარებული სესია აგრძელებს მუშაობას მას შემდეგ, რაც ვინმეს ჯგუფიდან ამოიღებთ. ამიტომაც ახალი სესია შეიძლება ჩავარდეს, სანამ ძველი კვლავ მუშაობს, და ამიტომ ორი მომხმარებელი ერთნაირი ჯგუფების სიით შეიძლება სხვადასხვა შედეგით დარჩეს.
ცვლილების ძალაში შესვლისთვის საჭიროა ახალი ავტორიზაციის გადაწყვეტილება და არა მხოლოდ ახალი გასაღებები. სადაც სერვერი მხარს უჭერს RFC 5176 დინამიკურ ავტორიზაციას, Disconnect-Request ან CoA-Request UDP 3799-ზე აიძულებს სესიის ხელახლა შეფასებას; წინააღმდეგ შემთხვევაში გათიშეთ კლიენტი და მიეცით ხელახლა დაკავშირების საშუალება. რენეგოციაცია აახლებს გვირაბის გასაღებებს და ჩვეულებრივ ხელუხლებლად ტოვებს ავტორიზაციის შედეგს, ამიტომ მისი ნებართვების განახლებად მიჩნევა წინააღმდეგობრივ ტესტის შედეგებს იძლევა.
შეასწორეთ პირობა და არა ჯგუფი
როცა იცით, რომელი პოლიტიკა ამოქმედდა, შესწორება ჩვეულებრივ მცირეა: გადააწყვეთ უარყოფა, რომელიც ჩრდილავს სასურველ დაშვებას, დაამატეთ ნაკლული მოწყობილობის ან MFA-ს პირობა იმ პოლიტიკას, რომელზეც უნდა დამთხვეოდა, ან დაწერეთ ვიწრო წესი ერთი რესურსისთვის იმის ნაცვლად, რომ მომხმარებელი აწიოთ ჯგუფში, რომელიც კიდევ ათ სხვას ატარებს. წევრობის გაფართოება ბილეთის დახურვისთვის იმავე შესწორების ძვირი ვერსიაა, და სწორედ ასე იქცევა მხარდაჭერის მალსახმობი მუდმივ გამონაკლისად, რომელსაც არავინ განიხილავს.
მოკლე ციკლი ცვლილებას პატიოსნად ინახავს:
- გაიმეორეთ უარყოფა ორიგინალური ანგარიშით და ჩაწერეთ ივენთის ID, სანამ რამეს შეცვლით.
- შეცვალეთ ერთი ობიექტი — პოლიტიკის რიგი, ერთი პირობა ან ერთი ჯგუფი — და ჩაინიშნეთ რომელი.
- გახსენით ახალი სესია, დაადასტურეთ, რომ დაშვება ლოგში ჩანს, და დაადასტურეთ, რომ რესურსი ნამდვილად იხსნება.
- გამოსცადეთ მომხმარებელი, რომელიც ჯერ კიდევ უნდა იყოს უარყოფილი, რათა შესწორებამ პოლიტიკა შემთხვევით არ გააფართოოს.
თუ დაშვება სწორია და რესურსი მაინც არ იხსნება, პრობლემა გადავიდა მარშრუტიზაციაზე ან სახელების რეზოლუციაზე — ეს ხდება მაშინ, როცა ავტორიზაცია წარმატებით დასრულდა. ეს ორი წარუმატებლობა ცალ-ცალკე გაარჩიეთ და შემდეგი ბილეთი წუთებში დაგილაგდებათ და არა ერთ შუადღეში.