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

დაკავშირებული ანგარიში ქსელის კატეგორია არ არის

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

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

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

სამი კატეგორია, რომელთაგან ერთს ვერ დააყენებთ

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

CategoryHow it is assignedWhat it affects
PublicDefault for unidentified networks, or set manuallyRules scoped to the public profile
PrivateSet manually, or by the user on a trusted networkRules scoped to the private profile
DomainAuthenticatedDetermined by Windows after domain authenticationRules scoped to the domain profile
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

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

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

წესები მიჰყვება პროფილს, რომლისთვისაც დაიწერა

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

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

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

დაადგინეთ, რომელი მანქანა აწესებს წესს

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

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

გაითვალისწინეთ მიმართულებაც. შემავალი SMB-ის დამშვები წესი არაფერს აკეთებს იმ კლიენტისთვის, რომლის საკუთარი გამავალი წესიც იმავე ტრაფიკს ბლოკავს. ფაილების დათვალიერების ფანჯრიდან ორივე ჩავარდნა განურჩეველია, ამიტომ ყოველი მიმართულება ცალკე გამოსცადეთ, სანამ რამეს შეცვლით.

რა უნდა გააკეთოთ ყველაფრის ხელახლა მონიშვნის ნაცვლად

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

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

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

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

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

დაკავშირებული სტატიები