დაბლოკავს თუ არა თქვენი დამცავი გადამრთველი იმ აპს, რომელიც გვირაბიდან გამორიცხეთ?
გამორიცხული აპი შეიძლება განზრახ პირდაპირ წავიდეს, ხოლო დაცული აპი უნდა ჩავარდეს დახურული. ჯერ დაწერეთ პოლიტიკა თითოეული აპისთვის, შემდეგ შეამოწმეთ, რას ახორციელებს კლიენტი.
დამცავი გადამრთველი ჩართულია, აპი განზრახ გამორიცხულია გვირაბიდან და ორი მოთხოვნა ახლა ეწინააღმდეგება ერთმანეთს. ერთი ამბობს, რომ ვერაფერი გავა გვირაბის გარდა, მეორე ამბობს, რომ ეს პროგრამა პირდაპირ უნდა წავიდეს. თითოეული კლიენტი ამ კონფლიქტს სხვანაირად წყვეტს და პარამეტრების გვერდი იშვიათად ხსნის, რომელი წესი იმარჯვებს. დაწერეთ პოლიტიკა თითოეული აპისთვის, სანამ რომელიმე იარლიყს დაეყრდნობით.
ორი პოლიტიკა, ერთი მანქანა
დამცავი გადამრთველი დაპირებაა წარუმატებლობის შესახებ: როცა გვირაბი ტრაფიკს არ იცავს, ტრაფიკი ჩერდება. გაყოფილი გვირაბი დაპირებაა არჩევანის შესახებ: ეს პროგრამები ან დანიშნულებები იყენებენ გვირაბს, ისინი კი არა. მეორე დაპირება ქმნის ტრაფიკს, რომელზეც პირველმა უნდა გადაწყვიტოს. არც ერთი დაპირება არ არის მცდარი; უბრალოდ სხვადასხვა ადამიანმა დაწერა ისინი სხვადასხვა საფრთხისთვის.
სამი შედეგია შესაძლებელი და მათგან მხოლოდ ერთია ის, რაც განლაგებას ჰქონდა განზრახული. გამორიცხული აპი შეიძლება დარჩეს პირდაპირ შეფერხების დროს, რაც პატივს სცემს გაყოფას და არღვევს გადამრთველს. ის შეიძლება დაიბლოკოს დანარჩენ ყველაფერთან ერთად, რაც პატივს სცემს გადამრთველს და არღვევს გაყოფას. ან დაიბლოკოს მხოლოდ ზოგჯერ, იმის მიხედვით, თუ როგორ აფასებს პლატფორმა წესს ინტერფეისის გაქრობის შემდეგ. სწორედ ეს უკანასკნელი შემთხვევა ქმნის ბილეთებს.
ჯერ აპების სია, შემდეგ წესი
ჩამოთვალეთ პროგრამები, რომლებმაც უნდა გამოიყენონ გვირაბი, ისინი, რომლებმაც უნდა წავიდნენ პირდაპირ, და სახელები ან დანიშნულებები, რომლებიც არასდროს არ უნდა გამოჩნდეს არც ერთ სიაში. ცალკე მიუთითეთ გადამწყვეტის ქცევა და IPv6 მხარე, რადგან ორივემ შეიძლება გვერდების ტრაფიკისგან განსხვავებული პოლიტიკა დაიცვას.
თითო აპის წესები ჩვეულებრივ ემთხვევა შესრულებად ფაილს ან პაკეტს და არა მის შიგნით არსებულ პროფილს. ბრაუზერის პროფილი, პირადი ფანჯარა და გაფართოება საკუთარ ქსელურ იდენტობას არ ატარებს, ამიტომ ისინი მემკვიდრეობით იღებენ იმას, რაც პროცესმა მიიღო. ამ ბრაუზერის მიერ გაშვებულმა დამხმარე პროცესმა შეიძლება საერთოდ არ მიიღოს იგივე წესი მემკვიდრეობით.
საჭიროა ორი სია და არა ერთი: რა უნდა ატაროს გვირაბმა და რა არ უნდა იმოგზაუროს მის გარეთ არც ერთი მიზეზით. აპი, რომელიც ორივეგან ჩანს, მოთხოვნების კონფლიქტია და არა განხორციელების დეტალი, და ის უნდა გადაწყდეს კლიენტის კონფიგურაციამდე.
რას აკეთებს კლიენტი შეფერხების დროს
ზოგიერთი განხორციელება შეფერხების დროს ბლოკავს გამორიცხულ აპებს და ხელახალი დაკავშირებისას უბრუნებს მათ წვდომას. სხვები ინარჩუნებენ პირდაპირ გზას მთელი დროის განმავლობაში, რაც შეესაბამება გაყოფას და სუსტია როგორც უსაფრთხოების თვისება. პლატფორმის დონის ჩაკეტვამ შეიძლება მთლიანად გადაფაროს კლიენტის საკუთარი არჩევანი თითო აპისთვის. ეს განსხვავება კოსმეტიკური არ არის, რადგან ის წყვეტს, გამორიცხული აპი პოლიტიკის გამონაკლისია თუ ხვრელი.
Android-ის ყოველთვის ჩართული VPN, VPN-ის გარეშე კავშირების ბლოკირების ოფციით, ყველაზე ნათელი შემთხვევაა, რადგან ჩაკეტვას პლატფორმა ახორციელებს და არა კლიენტი, და გამორიცხული პაკეტი იბლოკება დანარჩენ ყველაფერთან ერთად, სანამ გვირაბი გამორთულია. სამუშაო მაგიდის კლიენტი, რომელიც თითო აპის გამონაკლისებს საკუთარ დრაივერში იყენებს, ჩვეულებრივ გამორიცხულ პროცესს ფიზიკურ ინტერფეისზე ტოვებს, რადგან თავიდანვე ამ პროცესის ტრაფიკის მფლობელი არ იყო. ორივე ქცევა დასაცავია და მათგან მხოლოდ ერთი შეესაბამება მოთხოვნას, რომ გამორიცხული აპი გამოსაყენებელი უნდა დარჩეს. ჰკითხეთ, რომელი კომპონენტი ახორციელებს წესს, სანამ შედეგს განმარტავთ.
წაიკითხეთ იმ ოპერაციული სისტემის ქცევა, რომელიც თქვენ წინაშეა და არა სხვაგან იმავე სახელის მქონე პარამეტრი. აღსრულების API-ები განსხვავდება, და ერთმა მოსანიშნმა შეიძლება სამუშაო მაგიდაზე და ტელეფონზე სრულიად განსხვავებული რამ ნიშნავდეს. ვერსიასაც აქვს მნიშვნელობა, რადგან ჩაკეტვის კონტროლი Android-ის გამოშვებებს შორის ეკრანებს შორის გადაადგილდებოდა, და კლიენტის მხარეს არსებული გამონაკლისების სია არ არის იგივე კონტროლი, რაც პლატფორმის ჩაკეტვა.
სამი მომენტი: გვირაბი ჩართული, გვირაბი გამორთული, ხელახალი დაკავშირება
გამოიყენეთ უვნებელი მოთხოვნები სამ მომენტში: სანამ გვირაბი მუშაობს, იმ წარუმატებლობის დროს, რომელიც გაღელვებთ, და ხელახალი დაკავშირების შემდეგ. ერთი ბრაუზერის შედეგი ვერ დაადგენს გამორიცხული აპის ქცევას.
curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com
გასასვლელი მისამართი გვიჩვენებს, რომელი გზა აირჩიეს, ხოლო ინტერფეისის ცალსახა ტესტი გვიჩვენებს, რა ხდება, როცა გვირაბი ერთადერთი ხელმისაწვდომი გასასვლელია. ჩაწერეთ მოსალოდნელი შედეგი ყოველი ხაზის გვერდით, სანამ რომელიმეს გაუშვებთ, წინააღმდეგ შემთხვევაში გამოსავალი მოგვიანებით განიმარტება.
თუ გამორიცხული აპი ხაზგარეშე დარჩა, შეამოწმეთ პოლიტიკის უპირატესობა, სანამ ფართო ქსელურ დაშვებას დაამატებთ ცეცხლოვან კედელში, რადგან ეს შესწორება ანადგურებს იმ განსხვავებას, რომელსაც ამოწმებდით. თუ ის პირდაპირ დარჩა, დაადასტურეთ, რომ ეს იყო დოკუმენტირებული გამონაკლისი და არა შემთხვევითი უკუსვლა. მთელი მოწყობილობისთვის მკაცრი მოთხოვნის შემთხვევაში შეამცირეთ გამონაკლისების სია, სანამ ხელით შემოწმება შესაძლებელი გახდება.