აპლიკაციის kill switch firewall-ის kill switch-ის წინააღმდეგ: რას ბლოკავს თითოეული

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

ჯერ დაასახელეთ აღსრულების მექანიზმი

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

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

გადარჩება ბლოკირება კლიენტს?

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

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

მოძებნეთ ჩვეულებრივი ხვრელები

IPv6 პირველია. IPv4 მისამართებისთვის დაწერილი წესი IPv6 ტრაფიკს ხელუხლებლად ტოვებს და ბევრი კლიენტი მხოლოდ v4 ნახევარს წერს. მეორე ინტერფეისია: USB tethering, მეორე Wi-Fi ადაპტერი და მობილური მოდემი შეიძლება არ იყოს ჩართული ძირითად კავშირზე შეზღუდულ წესში. გამორიცხული აპლიკაციები და ლოკალური ქსელის გამონაკლისები მესამეა.

Windows-ზე შეგიძლიათ წაიკითხოთ დაყენებული წესები და არ ენდოთ გადამრთველს: Get-NetFirewallRule -DisplayName '*VPN*' და netsh wfp show filters ორივე აჩვენებს, რა არსებობს. Linux-ზე iptables -S, ip6tables -S და nft list ruleset ფარავს ჩვეულებრივ შემთხვევებს და სამივეს შედარებაა მთავარი.

DNS ჩვეულებრივი გაჟონვაა

TCP-ის დაბლოკვა იმ დროს, როცა UDP 53 ღია რჩება, გაძლევთ ძალიან დამაჯერებელ kill switch-ს, რომელიც მაინც პასუხობს ჰოსტის სახელის ყველა მოთხოვნას. იგივე ეხება მაშინ, როცა DNS სხვა ინტერფეისის რეზოლვერს გადაეცემა, ან როცა კლიენტი მხოლოდ v4-ს ბლოკავს და რეზოლვერი v6-ით ხელმისაწვდომია.

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

შეამოწმეთ გადასვლა და არა გადამრთველი

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

ერთი ლეპტოპის შედეგი არ გადადის ტელეფონზე ან როუტერზე. სხვადასხვა პლატფორმის API, სხვადასხვა ნაგულისხმევი მნიშვნელობა და Android-ზე განსხვავება მკვეთრია: ბლოკირებით always-on რეჟიმს სისტემა ახორციელებს და არა კლიენტი, ამიტომ ის აგრძელებს მუშაობას, როცა კლიენტი არ მუშაობს. Android-ის VPN სახელმძღვანელო აღწერს ამ გაყოფას.

შეინახეთ დაბრუნების გზა

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

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