თითო აპის kill switch ან მთელი მოწყობილობის ჩაკეტვა: რა იცვლება
გადაწყვიტეთ დაცული სიმრავლის მიხედვით და არა იარლიყის: რა ჩერდება გამორიცხული აპებისთვის, ფონური დამხმარეებისთვის და ახალი კავშირებისთვის და როგორ შეამოწმოთ თითოეული შემთხვევა.
თითო აპის kill switch ფრთხილი არჩევანივით ჟღერს: გვირაბის ჩავარდნისას ქსელს მხოლოდ სამუშაო კლიენტი კარგავს, დანარჩენი კი აგრძელებს მუშაობას. შემდეგ ვიღაც ამჩნევს, რომ პირადმა ბრაუზერმა მაინც ჩატვირთა გვერდი, იმავე პაკეტთან მოსული სინქრონიზაციის დამხმარე განაგრძობდა ცდას, და ქეშირებული სახელი კვლავ იხსნებოდა მისამართში, რომელსაც გვირაბი არასოდეს შეხებია. ფუნქციის იარლიყი და იმ კავშირების სიმრავლე, რომელსაც ის რეალურად იცავს, ორი განსხვავებული რამაა. ჯერ დაცული სიმრავლე განსაზღვრეთ, რადგან სწორედ ის წყვეტს, თითო აპის აღსრულება თუ მთელი მოწყობილობის ჩაკეტვაა პატიოსანი აღწერა.
დაიწყეთ სიმრავლით და არა იარლიყით
თითო აპის პოლიტიკა იცავს შერჩეულ აპებს. მოწყობილობის ჩაკეტვა უფრო ფართო ქსელურ საზღვარს მიმართავს, ჩვეულებრივ ლოკალური ბეჭდვის, მართვის ტრაფიკის ან ჩამჭრელი პორტალებისთვის დოკუმენტირებული გამონაკლისებით. არც ერთი იარლიყი არ არის სრული, სანამ სამ კითხვას არ უპასუხებთ: რა ხდება გამორიცხულ აპებთან, რა ხდება იმ დამხმარეებთან, რომლებსაც ეს აპები უშვებენ, და რა ხდება იმ კავშირებთან, რომლებიც იხსნება, როცა დაცვა მიუწვდომელია.
ეს პასუხები ჩაწერეთ სანამ კლიენტის რომელიმე პარამეტრს შეეხებით. თუ მოთხოვნაა, რომ "ამ სახელფასო კლიენტმა არასოდეს ისაუბროს ინტერნეტთან გვირაბის გარეთ, და ჩემს ბრაუზერს შეუძლია", სიმრავლე მცირეა და თითო აპის აღსრულება შეეფერება. თუ მოთხოვნაა, რომ "ამ მოწყობილობაზე არაფერი მიაღწიოს ინტერნეტს დაცვის გარეშე, განახლების სერვისის გარდა", არც ერთი თითო აპის პოლიტიკა ამას არ მოგცემთ, რადგან პრობლემა სწორედ ის აპებია, რომლებიც არ დაგისახელებიათ.
თითო აპის აღსრულება იდენტიფიკატორებს ემთხვევა და არა პროგრამების სახელებს
Android თითო აპის VPN-ს პაკეტების საშუალებით გვაძლევს, და მისი VpnService-ის დოკუმენტაცია აღწერს, როგორ ურთიერთქმედებს ეს მუდმივად ჩართულ რეჟიმთან და დაბლოკვასთან. iOS თითო აპის VPN-ს მართვის პროფილის საშუალებით აყენებს და აპის ან დომენის მიხედვით ემთხვევა. Windows-სა და Linux-ში პროცესის მიხედვით მარშრუტი საერთოდ არ არსებობს, ამიტომ იგივე იდეა მიახლოებით მიიღწევა პროგრამაზე შეზღუდული ფაირვოლის წესით ან წესით, რომელიც მფლობელ მომხმარებელს ემთხვევა.
საზღვარი იდენტიფიკატორია, და იდენტიფიკატორების გვერდის ავლა ადვილია. აპი, რომელიც URL-ს გადასცემს სისტემურ ბრაუზერს ან ხსნის დოკუმენტს დამთვალიერებელში, გადადის პროცესში, რომელსაც თქვენი პოლიტიკა არასოდეს დაუსახელებია. ჩავარდნისას დასრულების ვარიანტიც არ არის პაკეტების ფილტრი: ის კლავს თქვენს მიერ კონფიგურირებულ აპს, მაშინ როცა შვილობილი პროცესი, რიგის მუშაკი ან ბრაუზერის ჩანართი არსებულ სოკეტს ცოცხლად ინახავს.
ჩაკეტვა ფარავს იმას, რასაც თითო აპის პოლიტიკა ვერ ხედავს
მთელი მოწყობილობის ჩაკეტვა არჩევანს აშორებს. გვირაბს არ მიკუთვნებული ყოველი გამავალი პაკეტი იწაგება, მათ შორის იმ პროცესების ტრაფიკი, რომლებიც თქვენმა აპის პოლიტიკამ არასოდეს იცოდა. Android-ზე ეს არის მუდმივად ჩართული VPN კავშირების დაბლოკვის პარამეტრთან ერთად, და აღსრულება ხდება სისტემაში და არა კლიენტის ფანჯარაში. დესკტოპზე ეს არის მუდმივი ფაირვოლის წესი ან მიუწვდომელ კარიბჭეზე მიმართული ნაგულისხმევი მარშრუტი.
ფასი ისაა, რომ დანარჩენი ყველაფერი ჩერდება, ამიტომ გამონაკლისები დიზაინის ნაწილი ხდება და არა გვიანდელი ფიქრი. ლოკალურ პრინტერებს, სერვისების აღმოჩენას, ჩამჭრელ პორტალებში შესვლას, მართვის აგენტებსა და OS-ის განახლებებს თითოეულს დოკუმენტირებული ხვრელი სჭირდება, რადგან თითოეული გზაა, რომელიც ღია რჩება, როცა გვირაბი გამორთულია. ჩაკეტვა იმდენად ძლიერია, რამდენადაც მოკლეა ამ სიის ყველაზე მოკლე ჩანაწერი.
DNS, IPv6 და ფონური დამხმარეები გაჟონვებს მალავენ
ის, რომ დაცულმა აპმა სახელი ვერ გახსნა, არ ამტკიცებს, რომ ქეშირებული პასუხები ან პირდაპირი IP ტრაფიკი დაბლოკილია. თუ გამხსნელი ჯერ კიდევ მისაწვდომია გვირაბის გარეთ, სახელი იხსნება და კავშირი ფუჭდება, რაც მუშა kill switch-ს ჰგავს და არ არის. უფრო უარესი, ქეშირებულმა ჩანაწერმა შეიძლება მიუთითოს მისამართზე, რომელსაც გვირაბი არ ატარებს, ამიტომ კავშირი პირდაპირ გადის, მაშინ როცა აპი VPN შეცდომას აცხადებს.
IPv6-ს საკუთარი წესი სჭირდება ყოველ პლატფორმაზე, რომელიც მას ამუშავებს, რადგან v4-ისთვის ჩაგდების წესი v6 მარშრუტს არ ფარავს. მობილურზე პირადი DNS-ის პარამეტრმა შეიძლება გადაწყვეტა გადაიტანოს დაშიფრულ არხში, რომელსაც მოწყობილობის პოლიტიკა არ ამოწმებს. ფონური დამხმარეები კი დესკტოპის ჩვეულებრივი დამნაშავეები არიან: განახლების ან სინქრონიზაციის პროცესი VPN კლიენტამდე იწყება და საკუთარ კავშირს ინახავს, ამიტომ შეცვლილ მარშრუტს არასოდეს ხედავს.
შეამოწმეთ სამი აპი და ორი გადასვლა
| Test | What it proves |
|---|---|
| Included app, by name and by direct IP | the policy is applied, not just the resolver |
| Excluded app, same checks | the exclusion is intentional and documented |
| Helper or updater process | nothing inherited an older route |
| Tunnel drop, then Wi-Fi to cellular | the block survives the transition |
თითოეული რიგი ორჯერ გაუშვით: ერთხელ ჰოსტის სახელით და ერთხელ პირდაპირი მისამართით, და კიდევ ერთხელ IPv6-ზე, თუ ქსელი ამას გვთავაზობს. წარმატება ნიშნავს, რომ ჩართული აპი გაჩერდა, გამორიცხული აპი ისე მოიქცა, როგორც დაწერეთ, და დამხმარე არ გაძვრა. ჩაწერეთ ის პირდაპირი ქცევა, რომელიც მისაღებად ჩათვალეთ, რათა შემდეგმა ადმინისტრატორმა განასხვავოს განზრახ გამონაკლისი ხარვეზისგან.
შემდეგ აღწერეთ შედეგი ერთი წინადადებით, რომელიც ასახელებს აპებსა და პირობებს, მაგალითად: სახელფასო კლიენტს გვირაბის გარეთ მარშრუტი არ აქვს, ბრაუზერი დიზაინით პირდაპირია, და დანარჩენი ყველაფერი ჩერდება, როცა გვირაბი გამორთულია. თუ ამ წინადადების დაწერა ძნელია, პოლიტიკა ჯერ კიდევ ორი ერთმანეთთან მებრძოლი პოლიტიკაა.