VPN კლიენტები დაბლოკილია Windows-ის საჯარო დაცვის კედლის პროფილით

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

გაარკვიეთ, რომელ პროფილზე მოდის ტრაფიკი რეალურად

Windows-ის დაცვის კედელს არ აქვს ერთი გლობალური რეჟიმი. ყოველი დაკავშირებული ინტერფეისი ატარებს კატეგორიას და შემომავალი პაკეტები იფილტრება იმ ინტერფეისის კატეგორიით, რომლითაც ისინი მოდიან, ამიტომ გვირაბში მყოფი კლიენტის მისაწვდომობას VPN ადაპტერის პროფილი წყვეტს და არა გვერდით მდგარი Wi-Fi ან Ethernet ადაპტერი. წაიკითხეთ ორივე ფაქტი, სანამ რამეს შეცვლით:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

OpenVPN-ის ან WireGuard-ის სტანდარტული ინსტალაციისას VPN ადაპტერი ჩნდება როგორც ამოუცნობი ქსელი და ხვდება საჯარო პროფილში, რაც ნაგულისხმევია ნებისმიერი ქსელისთვის, რომელსაც Windows ვერ აკლასიფიცირებს: არც ერთი დომენის კონტროლერი არ გამოხმაურებია მასზე და არც ერთი კარიბჭის პროფილი არ დამთხვევია. ინტერფეისის სახელს აქ მნიშვნელობა არ აქვს, ამიტომ ადაპტერის „VPN“ ან „Corp“ დარქმევა არაფერს ცვლის. DomainAuthenticated მოითხოვს დომენზე მიერთებულ მანქანას , რომელსაც ეს ინტერფეისი ნამდვილად აძლევს დომენის კონტროლერზე მიღწევის საშუალებას; გაყოფილი გვირაბი, რომელიც მხოლოდ ერთ ქვექსელს ატარებს, ამ მოთხოვნას არ დააკმაყოფილებს.

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

დაადასტურეთ ფილტრაცია და არა მარშრუტიზაცია, სანამ წესებს შეცვლით

Ping სუსტი ტესტია. ICMP შეიძლება გაიაროს, სანამ სერვისის პორტი იშლება, და ჰოსტმა შეიძლება LAN-იდან უპასუხოს, ხოლო იგივე მოთხოვნა გვირაბით უარყოს. შეამოწმეთ პორტი, რომელიც კლიენტს სჭირდება, თავად კლიენტიდან:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

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

როცა შედეგი ჯერ კიდევ ორაზროვანია, ჩაწერეთ ჩამოგდებები ჩართული პროფილისთვის და წაიკითხეთ ისინი:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

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

შეზღუდეთ ერთი შემომავალი წესი კლიენტების პულზე

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

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

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

პროფილის არჩევანი ის ადგილია, სადაც იგივე შეცდომა საპირისპირო მიმართულებით კეთდება. -Profile Public საკმარისია, როცა ადაპტერი საჯაროა და საჯაროდ რჩება. -Profile Any გამართლებულია, როცა სერვისმა უნდა იმუშაოს მიუხედავად იმისა, როგორ აკლასიფიცირებს Windows ადაპტერს, მაგრამ მხოლოდ მანამ, სანამ დისტანციური არე რჩება. ის, რაც არასოდეს არის გამართლებული, არის -RemoteAddress Any საჯარო პროფილში: ეს წესი ლეპტოპს მიჰყვება ყოველ კაფესა და სასტუმროს ქსელში, რომელსაც უერთდება, და პორტს ხსნის ყველასთვის, ვინც ამ ქვექსელს იზიარებს.

ჩაწერეთ პული წესის გვერდით. -RemoteAddress 10.8.0.0/24 ჩუმად წყვეტს დამთხვევას იმ დღეს, როცა VPN პული ხელახლა ინომრება, და ხარვეზი ზუსტად ორიგინალ შეცდომას ჰგავს, ამიტომ მეორე შუადღე ღირს. დაარქვით წესებს სახელი სერვისისა და წყაროს დიაპაზონის მიხედვით, შეინახეთ ისინი ერთად -Group-თან, და გადაიკითხეთ ისინი ყოველ ჯერზე, როცა პულის განმარტება იცვლება. წესების ინვენტარი, რომელსაც ერთ ეკრანზე გადახედავთ, სჯობია სწორ წესს, რომელსაც ვერავინ პოულობს.

შეცვალეთ კატეგორია მხოლოდ მაშინ, როცა კატეგორია გადაწყვეტილებაა

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

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

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

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

გადაამოწმეთ ორივე მხრიდან და დატოვეთ კვალი

გადაამოწმეთ მომხმარებლის მიერ მოხსენებული ნაკადი, კლიენტიდან, ცვლილების შემდეგ:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

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

სანამ დასრულებულად ჩათვლით:

• წესში დასახელებული პროფილი არის იმ ინტერფეისის პროფილი, რომლითაც ტრაფიკი მოდის.
• დისტანციური არე არის VPN პული და ეს პული შეესაბამება იმას, რასაც სერვერი რეალურად გასცემს.
• არც ერთი თქვენ მიერ დამატებული წესი არ იყენებს -RemoteAddress Any საჯარო პროფილში.
• არაფერი გამორთულა იმისთვის, რომ ტესტი გავიდეს, და კატეგორიის ყოველი ცვლილება აღრიცხავს, ვინ დაამტკიცა ის.