რატომ VPN მდგომარეობაზე მიბმული firewall-ის კარიბჭე არ არის მხოლოდ გვირაბით ping-ის წესი

წარმოიდგინეთ firewall-ის წესი, რომელიც ჩართავს ICMP echo-ს სერვერის საჯარო მისამართისთვის ყოველ ჯერზე, როცა დასახელებული VPN პროფილი დაკავშირებულია. ის იკითხება როგორც „ping მხოლოდ გვირაბით“, და ეს წაკითხვა არასწორია ისე, რომ მნიშვნელოვანია. წესი არ ზღუდავს, ვის შეუძლია ჰოსტამდე მისვლა; ის ცვლის იმას, რასაც პასუხობს საჯარო ინტერფეისი, სანამ სხვა კავშირი შემთხვევით აქტიურია. ეს ორი განსხვავებული პოლიტიკაა, და ერთი მათგანი ჩუმად აფართოებს ზემოქმედებას.

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

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

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

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

რას აკონტროლებს კარიბჭე სინამდვილეში

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

თუ მოთხოვნა ნამდვილად მხოლოდ VPN-ის პარტნიორებია, მოცულობა პასუხობს მას კავშირის მდგომარეობის რაიმე ლოგიკის გარეშე: მიაბით წესი გვირაბის ინტერფეისს ან გვირაბის მისამართების დიაპაზონს, შეზღუდეთ დისტანციური მისამართები კლიენტთა აუზით და მიუთითეთ echo-ს ტიპი „ICMP“-ის ნაცვლად. ეს წესი სწორი რჩება, როცა არც ერთი VPN არ არის ჩართული, და შეუსაბამო პროფილი ვერ გახსნის მას.

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

ააგეთ ობიექტი ერთხელ, შემდეგ გადართეთ

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

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

სახელი მდგრადი იდენტიფიკატორია; ჩვენების სახელი დოკუმენტაციაა, რომლის რედაქტირებაც ადამიანს შეუძლია. შეათანხმეთ -Name-ზე და script შეწყვეტს დუბლიკატების შექმნას. ბრძანების იგივე ფორმა ფარავს IPv6-ის შემთხვევას -Protocol ICMPv6 -IcmpType 128-ით, მაგრამ ეს ცალკე წესია, რადგან echo-ს ტიპის ნომრები ორ ოჯახს შორის განსხვავდება.

შეინახეთ მისამართების ოჯახი და ICMP ტიპი ცხადად მეორე მიზეზის გამოც: -Protocol ICMPv4 ტიპის გარეშე უშვებს ყველა ICMPv4 შეტყობინებას, რომელსაც პროფილი უშვებს, მათ შორის იმათაც, რომელთა მიღებასაც არასდროს აპირებდით. ტიპი 8-ის დასახელება ვიწროვებს წესს echo-ს მოთხოვნამდე, და სწორედ ეს არის ერთადერთი, რასაც ხელმისაწვდომობის შემოწმება აგზავნის.

სად ეწინააღმდეგება ავტომატიზაცია განზრახვას

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

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

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

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