SMB firewall წესის LocalSubnet VPN კლიენტებს არ დაფარავს
LocalSubnet-ის დაშვების წესი ფარავს სერვერის საკუთარ ქვექსელებს და არა მარშრუტიზებულ VPN პულს. სანამ ფარგლებს გააფართოვებთ, შეადარეთ წყაროს მისამართი, რომელსაც სერვერი ხედავს.
ოფისის დესკტოპები აღწევენ საერთო რესურსამდე, VPN მომხმარებლებს დრო ეწურებათ, და იგივე ანგარიში მუშაობს მობილური ჰოტსპოტიდან. საერთო რესურსის ნებართვები იშვიათად არის განსხვავება; ჩვეულებრივ განსხვავებაა მისამართი, რომელიც ფაილურ სერვერამდე აღწევს. LocalSubnet-ზე შემოფარგლული წესი უშვებს სერვერის საკუთარ დაკავშირებულ ქვექსელებს, და ცალკე მარშრუტიზებული VPN პული მათგან ერთი არ არის. ორი დიზაინი ხურავს ამ ხარვეზს და ტოვებს ძალიან განსხვავებულ ჩანაწერებს.
ორი დიზაინი, ერთი სიმპტომი
პირველი დიზაინი VPN პულს ამატებს წესის დისტანციური მისამართის პირობას. შემდეგ სერვერი ხედავს თითოეული კლიენტის გვირაბის მისამართს, ამიტომ მისი ჟურნალები ერთ დისტანციურ მომხმარებელს მეორისგან აცალკევებს. მეორე დიზაინი VPN ტრაფიკს გადაამისამართებს გეითვეის მეშვეობით, რომელიც მას LAN მისამართად თარგმნის სანამ სერვერი ნახავს. ეს აღადგენს კავშირს და იმავე ნაბიჯში აშორებს განსხვავებას.
ცხრილი აღწერს როლებს და არა მისამართებს, და თქვენი საკუთარი პრეფიქსები წყვეტენ რომელი სტრიქონი ვრცელდება. დაბეჭდეთ სერვერის რეალური მნიშვნელობები ბლოგის პოსტიდან მაგალითის კოპირების ნაცვლად:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthცხრილი გადაწყვეტილების დამხმარე საშუალებაა და არა მტკიცება ყოველი განლაგების შესახებ. ჰოსტს დამატებითი ინტერფეისებით, მეორე საიტის ბმულით ან სხვა ნიღბით სხვა ლოკალური ნაკრები აქვს.
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
Microsoft-ის New-NetFirewallRule-ის ცნობარი აღწერს დისტანციური მისამართის პირობებს და LocalSubnet საკვანძო სიტყვას. წაიკითხეთ იგი სანამ გადაწყვეტთ, რომ საკვანძო სიტყვა ნიშნავს ყველა კერძო მისამართს, რადგან ასე არ არის.
შეადარეთ რას იღებს სერვერი სინამდვილეში
წაიკითხეთ მოქმედი წესი და არა ის, რომლის შექმნაც ვიღაცას ახსოვს. შეამოწმეთ, რომ ის ჩართულია, ვრცელდება აქტიურ პროფილზე და მისი დისტანციური მისამართის პირობა ემთხვევა წყაროს, რომელსაც სერვერი ხედავს. მხოლოდ Domain პროფილზე ჩართული წესი არაფერს აკეთებს, როცა ადაპტერი ქსელის ცვლილების შემდეგ Public-ზე გადავიდა.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionპირველი ბრძანება ბეჭდავს ფაილების გაზიარების წესებზე მიმაგრებულ მისამართის ფილტრებს, ხოლო მეორე აჩვენებს რომელი პროფილებია აქტიური და როგორ მუშავდება შეუსაბამო შემომავალი ტრაფიკი. მოძებნეთ ასევე დაბლოკვის წესი და ცენტრალიზებულად მართული პოლიტიკა. დაბლოკვის წესებს უპირატესობა აქვს დაშვების წესებზე, და ლოკალური წესების შერწყმის გამორთვადი პოლიტიკა ახალ ლოკალურ გამონაკლისს უმოქმედოს გახდის.
ეს ის შემთხვევაა, როცა წესი კონსოლში სწორად გამოიყურება და ტრაფიკზე გავლენას არ ახდენს. იმავდროულად შეამოწმეთ პროფილის მინიჭება, რადგან სხვა ქსელში გაწევრიანებულ ლეპტოპს შეუძლია Public პროფილზე გადაინაცვლოს ვინმეს firewall-ზე ხელის შეუხებლად.
შეამოწმეთ ტრანსპორტი შესვლამდე
გამოჰყავით ხელმისაწვდომობა აუთენტიფიკაციისგან. TCP 445-ზე მსმენელი ადასტურებს, რომ სერვისი პორტზეა მიბმული; ის არ ადასტურებს, რომ დისტანციურ პაკეტს შეუძლია მასთან მიღწევა. დასრულებული TCP კავშირი, თავის მხრივ, ჯერ არაფერს ამბობს SMB სესიის დამყარებაზე ან გაზიარების ნებართვებზე. შეამოწმეთ ხელის ჩამორთმევა ორივე მხრიდან სანამ წესს შეცვლით.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailedპირველი ბრძანება იუწყება, წარმატებულია თუ არა TCP ხელის ჩამორთმევა იმ აპარატიდან, სადაც ამოქმედებთ, ხოლო მეორე ამატებს ამოხსნილ მისამართს და ინტერფეისის დეტალებს. გაუშვით VPN კლიენტიდან და ოფისის დესკტოპიდან, შემდეგ შეადარეთ. Ping არც ერთ კითხვას არ პასუხობს, რადგან ICMP შეიძლება დაბლოკილი იყოს სანამ SMB ღიაა, ან დაშვებული სანამ firewall აგდებს 445-ს.
თუ ხელის ჩამორთმევა მხოლოდ VPN-იდან ვერ ხერხდება, წყაროს ფარგლები მთავარი ეჭვმიტანილია. თუ ის წარმატებულია და საერთო რესურსი მაინც გიშლით ხელს, გადადით SMB სესიისა და ნებართვების დიაგნოსტიკაზე firewall წესების რედაქტირების ნაცვლად.
როცა წყაროს NAT აშორებს განსხვავებას
როცა გზაზე თარგმანია, სერვერი ცალკეულ VPN კლიენტებს მისამართით ვერ გაარჩევს. ყოველი დისტანციური მომხმარებელი გეითვეის სახით მოდის. ნებისმიერი ავტორიზაცია, რომელიც მათ გარჩევაზეა დამოკიდებული, უნდა განხორციელდეს იქ, სადაც მათი იდენტობები ჯერ კიდევ ჩანს, რაც ჩვეულებრივ ნიშნავს VPN კონცენტრატორს ან აუთენტიფიკაციის პროქსის. Firewall წესს შეუძლია ტრაფიკის გატარება; მას არ შეუძლია იმ განსხვავების აღდგენა, რომელიც თარგმანმა მოხსნა.
როგორც კი ეს გეითვეის მისამართი დაიშვება, ყოველი დისტანციური მომხმარებელი ერთი მისამართის ქვეშ ირიცხება, ამიტომ წესი მთელ პულს აძლევს ყველას, ვისაც გეითვეიმდე მიღწევა შეუძლია. თუ თითო მომხმარებლის გადაწყვეტილება მნიშვნელოვანია, შეინარჩუნეთ ორიგინალური მისამართები ხილული ან გადაიტანეთ გადაწყვეტილება ფენაზე, რომელიც ჯერ კიდევ იცნობს მომხმარებელს. წინააღმდეგ შემთხვევაში ყოველი დისტანციური მომხმარებელი მემკვიდრეობით იღებს იმ ერთი მისამართის ნებართვებს, რომელსაც სერვერი ხედავს, და აუდიტის კვალი მათ შემდეგ ვეღარ გაარჩევს. ეს დიზაინის გადაწყვეტილებაა და არა firewall-ის დეტალი.
შეგნებულად აირჩიეთ ორ დიზაინს შორის. შეზღუდეთ წესი რეალურ VPN პულზე, როცა სერვერმა უნდა დაინახოს ვინ დაუკავშირდა, და მიიღეთ თარგმნილი გზა მხოლოდ მაშინ, როცა სერვერს ეს ინფორმაცია ნამდვილად არ სჭირდება. ჩაწერეთ არჩეული წყაროს დიაპაზონი წესის გვერდით, რადგან ამის გამმართავი შემდეგი ადამიანი პირველად მისამართების ცხრილს შეხედავს.