Ping მხოლოდ ერთი მიმართულებით მუშაობს: რატომ ყრის Windows სერვერის ექოს

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

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

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

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

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

ამრიგად, კლიენტის წარმატებამ დაამტკიცა, რომ გამავალი ICMP და დაბრუნების გზა მუშაობს. მან არასდროს გამოსცადა შემომავალი გადაწყვეტილება, და ბუნებრივი დასკვნა, რომ firewall რიგზეა, გონივრული და მცდარია. ამიტომაც ეს შეცდომა მეორდება იმ ბილეთებში, რომლებშიც მტკიცებულება უკვე არის.

მიჰყევით პაკეტს, სანამ ის გაქრება

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

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

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

შემოიფარგლეთ ერთი წესით და ნუ გახსნით ICMP-ს

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

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

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

რას არ ფარავს წესი

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

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

წაიკითხეთ შედეგი სწორი მიმართულებით

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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

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