Firewall პროფილები და VPN გასასვლელი: რატომ საჯარო გზა არ არის
Firewall პროფილი ირჩევს, რომელი წესების ნაკრები მოქმედებს. ის არაფერს ამბობს იმაზე, რომელი ინტერფეისი ატარებდა პაკეტს, და მკაფიო ბლოკირება უფრო ვიწრო ნებართვას სჯობს.
წესი ზუსტად ჟღერს: ნება დართე ლოკალურ ტრაფიკს პირად პროფილში და მხოლოდ VPN ტრაფიკს საჯაროში. ასე არ არის, რადგან ქსელის პროფილი ირჩევს, რომელი firewall წესების ნაკრები მოქმედებს და არაფერს ამბობს იმაზე, რომელი ადაპტერი ატარებდა პაკეტს. პროფილის სახელის გზის მოთხოვნად მიჩნევა ის შეცდომაა, რომლის გამოც შეზღუდული გასასვლელის დიზაინი დასრულებულად გამოიყურება, სინამდვილეში კი არ არის.
ჯერ ჩამწერეთ დინებები, შემდეგ გადაწყვიტეთ, რომელი მექანიზმი შეიძლება თითოეული მათგანის ნამდვილად აღსრულება. ეს დინებების სია ერთადერთი არტეფაქტია, რომელიც შემდეგ წესების ცვლილებას გადაურჩება.
კატეგორია ირჩევს წესებს და არა მარშრუტებს
როცა Windows ქსელს საჯაროდ ან პირადად ახარისხებს, firewall იყენებს ამ პროფილისთვის კონფიგურირებულ წესების ნაკრებს. კლასიფიკაცია მიჰყვება ქსელს, რომელსაც ადაპტერი შეუერთდა, და წესების ნაკრები წყვეტს, რა არის მასზე დაშვებული. არც ერთი ეს ფაქტი არ არის დამოკიდებული იმაზე, გამოიყენა თუ არა აპლიკაციის ტრაფიკმა გვირაბი. სწორედ ეს დამოუკიდებლობაა მთელი სირთულე.
გზის არჩევანს მარშრუტიზაცია აკეთებს, ინტერფეისის მეტრიკისა და იმ პრეფიქსის მეშვეობით, რომელსაც გვირაბი აყენებს. ამიტომ პროფილი შეიძლება საჯაროდ იყოს მონიშნული, მაშინ როცა აპლიკაციის კავშირი ფიზიკურ გზას მიჰყვება, და firewall მაინც შეატყობინებს, რომ საჯარო წესების ნაკრები იქნა გამოყენებული.
ამიტომ პროფილზე შემოფარგლული წესი ვერ ნიშნავს მხოლოდ გვირაბს. ორივე თვისებას სხვადასხვა კომპონენტი წყვეტს და ერთი მეორეს ვერ ჩაანაცვლებს.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
მკაფიო ბლოკირება უფრო ვიწრო ნებართვაზე მაღლა დგას
Microsoft-ის firewall წესების სახელმძღვანელო განასხვავებს ნებართვას, როგორც ნაგულისხმევი ბლოკირების მოქმედების გამონაკლისს, მკაფიო ბლოკირებისგან, რომელიც ნებართვას ეწინააღმდეგება. მკაფიო ბლოკირებები იმარჯვებენ ამ კონფლიქტში და გამავალი წესები იმავე უპირატესობას ემორჩილება.
ამიტომ ყველაფრის დამბლოკავი წესის დამატების და მის ზემოთ მოთავსებულ უფრო ვიწრო ნებართვაზე დაყრდნობის პოპულარული რეცეპტი არ აკეთებს იმას, რასაც მისი ავტორი მოელის. Windows Firewall კონფლიქტს ადმინისტრატორის მიერ მინიჭებული წესების რიგით არ წყვეტს. ბლოკირება უბრალოდ მოქმედებს და დამაკავშირებელი აპლიკაცია დროის ამოწურვას იუწყება. წესი, რომელიც გამონაკლისს ჰგავდა, არასდროს ყოფილა თამაშში.
მხარდაჭერილი ფორმა არის ნაგულისხმევი უარის პოლიტიკა დამტკიცებული ნებართვის წესებით, სადაც ყოველი ნებართვა ასახელებს პროგრამას, სერვისს ან დანიშნულებას საკმარისად ზუსტად, რომ გადამოწმებადი იყოს. ასეთი დიზაინი აუდიტს უძლებს, რადგან ყოველი გამონაკლისი ხილულია და არც ერთი მათგანი არ არის დამოკიდებული შექმნის რიგზე.
ორი ურთიერთსაწინააღმდეგო წესი ერთ წესზე უარესია, რადგან შედეგი ქცევა ერთდროულად სწორი და აუხსნელია.
მიეცი გამავალ პოლიტიკას ერთი მფლობელი
მხარდაჭერილი VPN კლიენტი უკვე ინარჩუნებს საკუთარ ბლოკირების ქცევას და საკუთარ გამონაკლისებს ბოლო წერტილებისთვის. არაკოორდინირებული ხელით შექმნილი წესების დამატებამ შეიძლება ეს კლიენტი დატოვოს გვირაბის გარეთ, რომელიც მას კონფიგურაციისთვის სჭირდება, ან დატოვოს ღია მეორე გზა, რომელიც არავის შეუმჩნევია.
გადაწყვიტე, ვის ეკუთვნის გამავალი პოლიტიკა, სანამ წესებს დაწერ. კლიენტის საკუთარი კონფიგურაცია, მართული firewall პოლიტიკა, თუ მფლობელის მქონე დოკუმენტირებული ლოკალური გამონაკლისების სია. შემდეგ შეათანხმე ფენები იმის ნაცვლად, რომ ექსპერიმენტები დააწყო, სანამ რაღაც დაუკავშირდება. დასახელებული მფლობელი ისიც არის, ვისაც ეკითხები, როცა ორი ფენა არ თანხმდება.
შეინარჩუნე აღდგენის არხი, სანამ რამეს შეცვლი. საკუთარი მართვის გზიდან ჩაკეტილი დისტანციური მანქანა უარესი შედეგია, ვიდრე ის პოლიტიკის ხვრელი, რომელსაც კეტავდი. აღდგენის წესის გამართლება უფრო ადვილია, როცა ის წინასწარ არის დაწერილი, და უფრო ადვილი მოსაძებნი, როცა ცვლილება ცუდად წავა ისეთ საათში, რომელიც არავის უყვარს.
სცადე ოთხი შედეგი ნაცვლად იმისა, რომ იარლიყი წაიკითხო
პოლიტიკა იმდენად კარგია, რამდენადაც განასხვავებს შემთხვევებს, ამიტომ პროფილის იარლიყს საწყის წერტილად მიუდექი და არა შედეგად. ოთხი შედეგი გეტყვის, მუშაობს თუ არა: განზრახული LAN მოთხოვნა წარმატდება, დაფარული ინტერნეტ მოთხოვნა წარმატდება, აკრძალული პირდაპირი მოთხოვნა ვარდება, და გვირაბის ჩავარდნის შემთხვევა ისე იქცევა, როგორც დაპროექტდა, ნაცვლად ჩუმად უკან დახევისა. ჩაწერე ოთხივე შედეგი წესების ცვლილების გვერდით. ოთხი დასახელებული შემთხვევის ტესტის გეგმა საკმარისად მოკლეა ყოველ ჯერზე გასაშვებად და საკმარისად კონკრეტული, რომ ხმამაღლა ჩავარდეს.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
პირველი ბრძანება გვიჩვენებს, როგორ არის კლასიფიცირებული ყოველი დაკავშირებული ქსელი, რაც ხშირად არ არის ის, რაც წესის დამწერმა ივარაუდა. მეორე აჩვენებს ნაგულისხმევ მოქმედებას პროფილზე, ხოლო მესამე ჩამოთვლის ჩართულ გამავალ ბლოკირებებს, მათ შორის იმათაც, რომლებიც ჩუმად გააუქმებენ უფრო ვიწრო ნებართვას.
ქსელის ცვლილების შემდეგ ხელახლა გაუშვი ოთხივე შემთხვევა, რადგან პროფილი შეიძლება ხელახლა კლასიფიცირდეს, როცა მანქანა სხვა ქსელს უერთდება. შესაბამისი პროფილის იარლიყი არ არის მტკიცებულება იმისა, რომ გზა შენი განზრახული იყო.