დამცავი ჩამრთველი VPN-ის გათიშვის შემდეგ კვლავ ბლოკავს ტრაფიკს

გვირაბი გაქრა, ქსელის ხატულა ნორმალურად გამოიყურება და არაფერი იტვირთება. თქვენ გათიშეთ VPN, წაშალეთ ის ან გადატვირთეთ სისტემა, და ბლოკი, რომელიც უნდა დაგეცვათ კავშირის ჩავარდნისას, ჯერ კიდევ დგას. კლიენტის ფანჯარა ამას ვერ ხსნის, რადგან ბლოკავს არა კლიენტი: გადაწყვეტილება თქვენი სახელით ბირთვში ჩაიწერა და მის მოსაშორებლად არაფერი დარჩა. Windows-ში ეს მდგომარეობა Windows Filtering Platform-შია; Linux-ში ეს არის წესების ნაკრები iptables-ში ან nftables-ში, ხშირად სნეპშოტით, რომელიც ჩატვირთვისას ხელახლა გამოიყენება. შემდეგი არის ჩემი თანმიმდევრობა: წაიკითხეთ მდგომარეობა, წაშალეთ ყველაზე ვიწრო ობიექტი, რომელიც წარუმატებლობას ხსნის, შემდეგ იპოვეთ ის, რაც მას კვლავ აბრუნებს.

დამცავი ჩამრთველი ბირთვის მდგომარეობაა და არა პარამეტრი

დესკტოპის კლიენტები ბლოკირებას ახორციელებენ ფილტრებით, რომლებიც გვირაბის გარეთ ტრაფიკს კრძალავს. Windows-ში ეს არის WFP ფილტრები connect-redirect და transport დონეებზე, და ზოგი მათგანი მუდმივია: ისინი Base Filtering Engine-ის პოლიტიკის საცავში იწერება და მანქანის ჩატვირთვისას აღდგება, ნებისმიერი VPN პროგრამის გაშვებამდე. კლიენტები განსხვავდებიან იმაში, როდის ასუფთავებენ. ზოგი ფილტრებს გათიშვისას შლის, ზოგი მხოლოდ სუფთა გასვლისას, ზოგი კი მხოლოდ მაშინ, როცა ჩამრთველი ჯერ გამორთულია. წაშალეთ პროგრამა ბლოკის აქტიურობისას, ან მოკალით პროცესი და ფილტრები დარჩება.

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

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

Windows-ს თან ახლავს საჭირო ხელსაწყოები. გაუშვით ადმინისტრატორის კონსოლი და გადმოწერეთ პლატფორმის მდგომარეობა; დამპი სამუშაო დირექტორიაში wfpstate.xml-ად ჩაიწერება.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

XML-ში მოძებნეთ წასული ვენდორის სახელი, Block მოქმედება და დონე. connect-redirect და transport ფილტრები არიან ისინი, რომლებიც ჩვეულებრივ ტრაფიკს ამტვრევს; receive-accept დონის ფილტრი ჩვეულებრივ თქვენი მიზეზი არ არის. თუ Base Filtering Engine საერთოდ არ მუშაობს, სხვაგან ეძებეთ, რადგან სხვა ვერაფერი აღასრულებს ამ ფილტრებს.

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

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

წაიკითხეთ Linux-ის წესები იმ სინტაქსით, რომლითაც წაშლით

iptables -S წესებს იმავე ფორმით ბეჭდავს, რომლითაც დაემატა, ამიტომ გამომავალი პირდაპირ გამოდგება წაშლისთვის. iptables -L -v -n პაკეტების მთვლელებს ამატებს, და ეს მთვლელები გეუბნებიან, ნამდვილად ემთხვევა თუ არა წესი თქვენს წარუმატებელ მოთხოვნებს, თუ უბრალოდ ჯაჭვში ზის.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

წაიკითხეთ ჯაჭვების პოლიტიკები და არა მხოლოდ წესები: -P OUTPUT DROP ტრაფიკს ბლოკავს მაშინაც, როცა წესი არ ემთხვევა. IPv6 ცალკე შეამოწმეთ, რადგან კლიენტი, რომელიც ორივე ოჯახს აყენებს, IPv6 ბლოკს ტოვებს IPv4 წესების გაქრობის შემდეგ, და სიმპტომი მაშინ დამოკიდებულია იმაზე, რომელ ოჯახს ანიჭებს უპირატესობას აპლიკაცია. სადაც nftables გამოიყენება, გაუშვით nft list ruleset-იც; ორი ხელსაწყო თავსებადობის ფენით თანაარსებობს და ერთი სია სულაც არ აჩვენებს ყველა წესს, რომელსაც პაკეტის ჩაგდება შეუძლია.

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

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

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

მუდმივი ფილტრები ბოლო საშუალებაა. ისინი HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter-ის ქვეშ არიან, თითო მნიშვნელობა თითო ფილტრზე, GUID-ით. ჯერ გასაღები გაიტანეთ, ჩაიწერეთ GUID-ები, რომლებსაც შლით, წაშალეთ მხოლოდ ის მნიშვნელობები, რომლებიც წასულ კლიენტს ეკუთვნის, შემდეგ გადატვირთეთ, რომ ძრავამ მდგომარეობა თავიდან ააგოს. ნუ წაშლით მთელ გასაღებს და ნუ გამორთავთ Base Filtering Engine-ს: Windows Firewall და Defender მასზე არიან დამოკიდებული და ერთ გათიშვას უარესით გაცვლით.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

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

sudo iptables -D OUTPUT -p udp -j REJECT

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

იპოვეთ მფლობელი, რომელიც მას უკან აბრუნებს

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

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

შეამოწმეთ რეალური ტრაფიკით და არა ერთი ping-ით

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

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