გადაურჩება VPN-ის გამორთვის გადამრთველი გადატვირთვას? როგორ შევამოწმოთ
გადატვირთვა გადამრთველის შესახებ ნაკლებს გეუბნებათ, ვიდრე ფიქრობთ. შეამოწმეთ რომელი ფენა აღადგენს ბლოკირებას, როდის იწყება და როგორ შევამოწმოთ იგი შესვლამდე.
გადატვირთვა ყველაზე გავრცელებული გზაა, რომლითაც ადამიანები გამორთვის გადამრთველს ამოწმებენ და ეს არის ტესტი, რომელიც ყველაზე ხშირად იტყუება. კლიენტის მოსამზადებელი უჯრა მხოლოდ უპირატესობაა; მთავარია, უზრუნველყოფს თუ არა რაღაც ბლოკირებას იმ მომენტსა და იმ მომენტს შორის, როცა ქსელის დასტა ადის და როცა გვირაბი ნამდვილად დამყარებულია. Windows-ზე ეს რაღაც ჩვეულებრივ ფილტრია Windows Filtering Platform-ში, Linux-ზე ერთეულის მიერ ჩატვირთული წესების ნაკრები, macOS-ზე pf-ის ღუზა, Android-ზე სისტემის საკუთარი მუდამ-ჩართული და ჩაკეტვის დროშები. ეს მოწყობები გადატვირთვის დროს სრულიად განსხვავებულად იქცევიან და მხოლოდ პლატფორმის დონის მოწყობებია ადგილზე მანამ, ვიდრე ვინმე შევა სისტემაში.
გადატვირთვა სამ ცალკე კითხვას სვამს
გაყავით კითხვა. პირველი, არსებობს თუ არა პოლიტიკა დისკზე ისეთი ფორმით, რომელსაც ჩატვირთვისას რაღაც კითხულობს? მეორე, მუშაობს თუ არა ის მკითხველი მანამ, ვიდრე რაიმე ტრაფიკი გავა? მესამე, ფარავს თუ არა პოლიტიკა იმ ტრაფიკს, რომელიც გაწუხებთ, ანუ ყველა პროცესს, ორივე მისამართების ოჯახს და DNS-ს. „დიახ“ პირველზე და „არა“ მეორეზე ქმნის ზუსტად იმ ხარვეზს, რომელსაც ადამიანები აღწერენ როგორც გადატვირთვას რომ არ უძლებს გადამრთველს: ტრაფიკი გაშვებისას რამდენიმე წამით გადის გარეთ და არავინ ამჩნევს, ვიდრე ვინმე არ წავა საშემოწმებლად.
გამოყავით ფენები. შენახული ფაირვოლის წესების ნაკრები, ჩატვირთვისას დაწყებული სერვისი და კლიენტის უპირატესობა სამი სხვადასხვა ობიექტია სამი განსხვავებული სიცოცხლით. უპირატესობა გადატვირთვას უძლებს, რადგან კონფიგურაციის ფაილში მნიშვნელობაა. წესები ერთადერთია, რაც პაკეტებს ბლოკავს და ისინი ქრება იმ ბირთვთან ერთად, რომელიც მათ იჭერდა.
იპოვეთ ობიექტი, რომელიც ბლოკირებას აღადგენს
Linux-ზე netfilter-ის წესები ბირთვში ცხოვრობენ. არაფერი წერს მათ უკან ჩატვირთვისას, თუ თქვენ არ მოაწყვეთ ეს: iptables-save პლუს netfilter-persistent, nftables.service ტვირთავს /etc/nftables.conf, ან systemd-ის ერთეული, რომელიც თქვენს სკრიპტს უშვებს. შეამოწმეთ რა არის ჩართული და არა ის, რაც გახსოვთ, რომ დააყენეთ.
systemctl is-enabled nftables netfilter-persistent 2>/dev/null sudo nft list ruleset sudo iptables -S OUTPUT
ცარიელი წესების ნაკრები ჩატვირთვიდან რამდენიმე წამში სწორედ სათაურის კითხვის პასუხია. Windows-ზე ჰკითხეთ კლიენტის სერვისს, როგორ იწყება იგი, შემდეგ კი გამოიტანეთ პლატფორმის ფილტრის მდგომარეობა, სანამ გვირაბი დაშვებულია.
Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show stateმეორე ბრძანება wfpstate.xml-ს მიმდინარე საქაღალდეში წერს. მოძებნეთ დაბლოკვის მოქმედების მქონე ფილტრები, რომლებიც უკვე არსებობენ კლიენტის მიერთებამდე. Base Filtering Engine ჩატვირთვისას ადრე იწყება და აღადგენს მუდმივი დროშით დამატებულ ფილტრებს, ამიტომ ზოგიერთი გადამრთველი ტრაფიკს ბლოკავს ნებისმიერი კლიენტის ფანჯრის არსებობამდე, ზოგიერთი კი არა. macOS-ზე sudo pfctl -s info გვატყობინებს, ჩართულია თუ არა pf, sudo pfctl -s rules გვიჩვენებს რა არის ჩატვირთული და VPN კლიენტები ჩვეულებრივ თავიანთ წესებს ღუზას ამაგრებენ და არა მთავარ ნაკრებს. წესი, რომელიც utun3-ს ასახელებს, შემდეგი ჩატვირთვის შემდეგ სხვა ინტერფეისზე შეიძლება მიუთითოს, რადგან ეს ნომერი მუშაობის დროს ენიჭება.
უყურეთ უფსკრულს ქსელის ასვლასა და გვირაბის ასვლას შორის
საშიში ინტერვალი მთელი გადატვირთვა არ არის, ეს უფსკრულია. ინტერფეისი ერთ მომენტში იღებს იჯარას და ნაგულისხმევ მარშრუტს, VPN სერვისი სხვა მომენტში იწყება, ხოლო გვირაბი კიდევ უფრო გვიან ამოწმებს ვინაობას, ზოგჯერ მხოლოდ მას შემდეგ, რაც მომხმარებელი შევა და რწმუნებათა აგენტი იმუშავებს. თუ ბლოკირება ბოლოს გამოიყენება, უფსკრულში არსებული ყველაფერი ღიად გადის გარეთ.
systemd-ის ჰოსტებზე წაიკითხეთ თანმიმდევრობა და ნუ გამოიცნობთ. გაუშვით systemctl cat VPN-ის და ფაირვოლის ერთეულებზე და მოძებნეთ After= ან Before= მიმართებაში network-pre.target-სა და network-online.target. ფაირვოლის ერთეული, რომელიც დალაგებულია network-online.target შემდეგ, აგებს ინტერფეისთან; ხოლო ის, რომელიც დალაგებულია network-pre.target წინ და მის მიერ არის მოთხოვნილი, იმარჯვებს. Windows-ზე ეკვივალენტური კითხვები სერვისის გაშვების ტიპი და მისი დამოკიდებულებებია, რადგან Manual-ზე დაყენებული სერვისი ჩატვირთვის პროცესს ვერ დაბლოკავს. თუ თქვენი მოთხოვნა შესვლამდე ტრაფიკს მოიცავს, მას მხოლოდ მოწყობილობის დონის მოწყობა აკმაყოფილებს: Always On VPN-ის მოწყობილობის გვირაბი მანქანის სერტიფიკატით ამოწმებს ვინაობას და მომხმარებლის შესვლამდე უკავშირდება, და Microsoft აღწერს მოწყობილობის გვირაბის კონფიგურაციას მომხმარებლის გვირაბისაგან ცალკე. Android სხვა გზას ირჩევს, ახდენს მუდამ-ჩართული VPN-ის და მის გარეშე კავშირებს სისტემიდან ბლოკავს და არა აპლიკაციის პროცესიდან.
გაუშვით ტესტი, შემდეგ შეადარეთ ორი დროის ხაზი
გადატვირთეთ ისეთი დანიშნულებით, რომელიც არაფერი ღირს, თუ გაჟონავს, და დააფიქსირეთ მდგომარეობა უფსკრულის დროს და არა მის შემდეგ. ყველაზე სუფთა მეთოდი ჩატვირთვის დროის ზონდია: oneshot ერთეული ან დაგეგმილი ამოცანა, რომელიც იწყება რაც შეიძლება ადრე, აფიქსირებს ნაგულისხმევ მარშრუტს და ფაირვოლის მდგომარეობას, ცდილობს ერთ მოთხოვნას მოკლე ვადით და ლოკალურ ფაილს უმატებს სტრიქონს. შეადარეთ ეს ჩანაწერი journalctl -b -u-იდან ან სისტემის ჟურნალიდან მიღებულ VPN სერვისის დაწყების დროს.
შემდეგ გაუშვით ჩვეულებრივი ტესტი: გვირაბი ზემოთ, გაწყვიტეთ კავშირი, ნახეთ ბლოკავს თუ არა პირდაპირ ტრაფიკს, აღადგინეთ. მეორეში გავლა და პირველში ჩავარდნა ნორმალური შედეგია და ნიშნავს, რომ აღსრულება კლიენტის მხარესაა, გამოიყენება კლიენტის მიერთებისას და არა ჩატვირთვისას. ბოლო მანქანაზე, რომელიც შევამოწმე, ბლოკირება NetworkManager-ის გამომცხადებელი სკრიპტიდან მოდიოდა: არსებული და სწორი და უსარგებლო იმ წამებისთვის, სანამ ინტერფეისი ავიდოდა. ჩაწერეთ ორივე შედეგი, რადგან გადატვირთვის გადარჩენა მხოლოდ მაშინ ნიშნავს რამეს, როცა იტყვით რომელი ფენა გადაურჩა და რომელი მომენტიდან.
დახურეთ უფსკრული უკან დაბრუნების გზის გატეხვის გარეშე
თუ ჩატვირთვისას ბლოკირება აკლია, გადაიტანეთ აღსრულება ერთი ფენით ქვემოთ და ნუ დაამატებთ მეორე კლიენტის წესს. შეინახეთ წესების ნაკრები და ჩატვირთეთ იგი იმ ერთეულიდან, რომელიც ქსელის გამოსაყენებლად გახდომამდე არის დალაგებული, და დარწმუნდით, რომ ამ ერთეულს არ სჭირდება DNS-ის მოთხოვნა ან ქსელური მიმაგრება, რომელიც მან უნდა დაიცვას. ფარგლები ისეთივე მნიშვნელოვანია, როგორც დრო: მომხმარებლის ID-ზე ან cgroup-ზე შესაბამისი წესები ყველა სისტემურ დემონს ბლოკირების გარეთ ტოვებს, ხოლო მხოლოდ IPv4-ს მომუშავე ნაკრები IPv6-ს და DNS-ს ხელმისაწვდომს ტოვებს.
დაუტოვეთ საკუთარ თავს დაბრუნების გზა. მანქანას, რომელიც ჩატვირთვისას ყველაფერს ბლოკავს და შემდეგ ვერ ამოწმებს ვინაობას, საერთოდ არ აქვს ქსელი, და გამოსწორება ბლოკირების წაშლა როდია, არამედ რწმუნებების ან თანმიმდევრობის შეკეთება. შეინახეთ დოკუმენტირებული ლოკალური კონსოლის პროცედურა და ვიწრო, განზრახ გამონაკლისი იმისთვის, რაც გვირაბს ნამდვილად სჭირდება, მაგალითად სერვერის მისამართი და გვირაბამდე გამოყენებული გადამწყვეტი.
სანამ მოწყობას ენდობით, თანმიმდევრობით დაადასტურეთ ოთხი რამ. პოლიტიკა ინახება იქ, საიდანაც ჩატვირთვა კითხულობს. ის მკითხველი მუშაობს მანამ, ვიდრე ინტერფეისი გამოსაყენებელი იქნება. ბლოკირება ფარავს ორივე მისამართების ოჯახს და DNS-ს. VPN ჯერ კიდევ შეუძლია ვინაობის დადასტურება, სანამ ბლოკირება აქტიურია. როცა ოთხივე სრულდება, გადატვირთვა არაფერს ცვლის.