NPS-ის ჯგუფური პოლიტიკა VPN რესურსების აღსრულება არ არის

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

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

იპოვეთ პოლიტიკა, რომელმაც სესია რეალურად მიიღო

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

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

RADIUS პასუხი ინსტრუქციაა, არა ფილტრი

Filter-Id ატრიბუტი ფილტრების სიის სახელს ატარებს. ის არ აგზავნის პაკეტების ფილტრაციის წესების გადატანად ვარგის კრებულს, რომელსაც ყველა მიმღები გაიგებს, და ისეთი სახელის გაგზავნა, რომელიც კარიბჭეს არასდროს განუსაზღვრავს, საერთოდ არაფერს აღასრულებს. იგივე სიფრთხილე ეხება VLAN ატრიბუტებს: გვირაბის სესიის VLAN-ზე მიკუთვნება თავისთავად არ არის მარშრუტიზებული წვდომის წესი ამ მომხმარებლისთვის.

აქ არის ის, სადაც NPS-ის მხარეს სრულად მოჩვენებითი დიზაინი ჩუმად არაფერს აკეთებს. კარიბჭის მომწოდებლის დოკუმენტაციით დაადასტურეთ, რომელი ავტორიზაციის ატრიბუტია მხარდაჭერილი და რას აკეთებს მიმღები თითოეულით, იმის ნაცვლად, რომ ივარაუდოთ, რომ სტანდარტული ატრიბუტის სახელი სტანდარტულ ქცევას ნიშნავს.

განათავსეთ აღსრულება იქ, სადაც ტრაფიკი გადის

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

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

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

კლიენტის პროფილები არასანდო მხარეს ცხოვრობენ

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

კლიენტის პარამეტრებს მოეკიდეთ როგორც კომფორტს, კარიბჭის პარამეტრებს კი როგორც კონტროლს. როცა ორივე ეწინააღმდეგება ერთმანეთს, კარიბჭე მართალია, რადგან სწორედ ის ხედავს პაკეტებს.

მიიღეთ ორი ანგარიშით, შემდეგ თვალყური ადევნეთ რიგით

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

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