ბლოკავს firewall VPN-ს? ეტაპობრივი შემოწმება

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

ეტაპი 1: დაადასტურეთ სერვერი და ტრანსპორტი

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

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

ჩაწერეთ ორივე მნიშვნელობა ბილეთში. ყოველი შემდგომი შედარება მათ იყენებს და მათ გარეშე ბილეთი გამოძიებას თავიდან იწყებს.

ეტაპი 2: დაამტკიცეთ გზა ერთი კონტროლირებული შედარებით

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

ჯერ დაასრულეთ ნებისმიერი ლეგიტიმური ქსელური შესვლა, რადგან ჩაკეტილი პორტალი ბლოკირებას ჰგავს მანამ, სანამ დასრულდება.

შეამოწმეთ ის პორტი, რომელსაც რეალურად იყენებთ და TCP-ის შედეგი მიიღეთ როგორც ინფორმაცია მხოლოდ TCP-ზე.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

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

ეტაპი 3: წაიკითხეთ უსაფრთხოების მოვლენები წარუმატებლობის მომენტისთვის

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

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

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

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

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

ეტაპი 4: შეამოწმეთ გადაგზავნა გვირაბის აწევის შემდეგ

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

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

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

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

შეამოწმეთ შესწორება და მოხსენით ის, რაც არ დაეხმარა

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

ხელახლა გაუშვით იგივე სამი ბრძანება და შეადარეთ ისინი ცვლილებამდე შენახულ გამოსავლებს.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

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