ჰოტსპოტის კლიენტებისთვის გაყოფილი გვირაბი არ არის აპლიკაციით გამორიცხვა
აპლიკაციის VPN-იდან გამორიცხვა მხოლოდ ტელეფონს ცვლის. დაკავშირებულ ლეპტოპს საკუთარი გადაგზავნის წესი სჭირდება, რომელიც წყაროზე, დანიშნულებასა და NAT-ზეა შედარებული.
ორი მოთხოვნა, რომლებიც ერთნაირად ჟღერს, ერთი და იგივე არ არის: «გამორიცხე ეს აპლიკაცია VPN-იდან» და «გაგზავნე ეს ერთი დანიშნულება VPN-ის გარეთ ჩემს ჰოტსპოტზე მდგარი ლეპტოპისთვის». პირველი ცვლის იმას, როგორ ირჩევს ტელეფონზე სოკეტი ქსელს. მეორემ უნდა შეცვალოს გადაგზავნის გადაწყვეტილება პაკეტისთვის, რომელიც სხვა მოწყობილობიდან მოვიდა მას შემდეგ, რაც ტელეფონმა ის უკვე მიიღო. ამ ორის არევა იწვევს იმას, რომ ჰოტსპოტის კლიენტს რჩება გამონაკლისი, რომელიც ყოველთვის მხოლოდ თავად ტელეფონის ბრაუზერს ეხებოდა.
ორ კითხვას ორი ქვესისტემა ფლობს
Android აპლიკაციების ქსელსა და თეთერინგს ცალ-ცალკე ინახავს. აპლიკაციების სოკეტებს ქსელს კავშირის დასტა ანიჭებს, ხოლო VPN აპლიკაცია წყვეტს, რომელი მისი სოკეტიდან შევა გვირაბში. დაკავშირებული კლიენტიდან გადაგზავნილ პაკეტებს თეთერინგის ქვესისტემა ამუშავებს და netd-ს ჰკითხავს მარშრუტებს, პოლიტიკის წესებს და თარგმანს ქვედა ინტერფეისზე.
აპლიკაციით გამორიცხვა ფასდება მაშინ, როცა აპლიკაცია სოკეტს ხსნის. გადაგზავნილი პაკეტი ამ შემოწმებას ვერასოდეს აღწევს, რადგან ის ამ მოწყობილობის აპლიკაციის სოკეტიდან არ წარმოშობილა. ეს არის მთელი მიზეზი, რის გამოც ორი პარამეტრი ერთმანეთს ვერ ჩაანაცვლებს, და ეს არც ერთში შეცდომა არ არის.
რას ცვლის სინამდვილეში აპლიკაციით გამორიცხვა
VpnService-ის შემქმნელს შეუძლია addDisallowedApplication-ით დაასახელოს გვირაბის გარეთ დარჩენილი პაკეტები, ან addAllowedApplication-ით დაასახელოს შიგნით დაშვებული ერთადერთი პაკეტები. ეს აპლიკაციები შემდეგ სოკეტებს ხსნიან ქვედა ქსელში, სანამ VPN კვლავ ფლობს ნაგულისხმევ მარშრუტს ყველაფერ დანარჩენზე.
მოქმედების არე ზუსტია: თავად პაკეტის სოკეტები, ამ მოწყობილობაზე, სანამ გვირაბი აწეულია. ის არაფერს ამბობს გადაგზავნილ ტრაფიკზე, არაფერს მეორე მოწყობილობაზე და არაფერს იმ პაკეტებზე, რომლებსაც სისტემა თეთერინგის სახელით აგზავნის.
ეს დანიშნულების კონტროლიც არ არის. ბრაუზერის გამორიცხვა გამორიცხავს ყოველ მისამართს, რომელსაც ეს ბრაუზერი აღწევს, მათ შორის იმას, რომლის გვირაბში დატოვებაც გსურდათ. როცა მოთხოვნა აპლიკაციის ნაცვლად დანიშნულებას ასახელებს, აპლიკაციის ამრჩევი უკვე აგებულებით არასწორი ინსტრუმენტია.
როგორ გამოიყურება გადაგზავნილი პაკეტი ტელეფონისთვის
კლიენტის პაკეტი ჰოტსპოტის ინტერფეისზე მოდის ტელეფონის მიერ მინიჭებული კერძო წყაროს მისამართით, ვთქვათ 192.168.43.20, და საჯარო დანიშნულებით. მის გადასაგზავნად ტელეფონს სჭირდება მარშრუტი ზედა რგოლისკენ და თარგმანის წესი, რომ პასუხებმა უკან დაბრუნების გზა იპოვონ, რადგან კლიენტის კერძო მისამართი ფიჭურ ქსელში უაზროა.
Android ამას გამოხატავს პოლიტიკის წესებით, რომლებიც მარშრუტიზაციის ცხრილს ირჩევენ, და netd შესაბამის ცხრილებსა და წესებს თავიდან აგებს, როცა ქსელები და VPN-ები იცვლება. ფორუმის პოსტიდან ან იმავე მოდელის ძველი გამოშვებიდან კოპირებული ცხრილის ნომერი, წესის პრიორიტეტი ან ინტერფეისის სახელი მდგრად საკუთრებას არ აყალიბებს. სწორედ ეს გადაკეთებაა მიზეზი იმისა, რომ ხელით დაწერილი წესი შეიძლება საათი მუშაობდეს და შემდეგი ხელახალი დაკავშირების შემდეგ გაჩერდეს.
რა პოლიტიკა სჭირდება სინამდვილეში ჰოტსპოტის გამონაკლისს
წესზე ხელის მოკიდებამდე ჩაწერეთ გადაწყვეტილება წყაროდ, დანიშნულებად და განზრახულ გზად. ერთი დამტკიცებული დანიშნულების მინიმალური ფორმა ასე გამოიყურება:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
ორივე მიმართულება სრული უნდა იყოს. პირდაპირ ტოტს სჭირდება გამოსაყენებელი მარშრუტი ფიჭური ზედა რგოლით, რომელიც შემთხვევით ახლა მოქმედია; VPN ტოტს სჭირდება გვირაბის მარშრუტი და გადაგზავნის ნებართვა. ნებისმიერი წყაროს თარგმანი უნდა შეესაბამებოდეს თქვენს მიერ არჩეულ გასასვლელს, რადგან გვირაბის ინტერფეისზე გამოყენებული NAT გვირაბის მისამართს აჩვენებს და არა ფიჭურისას, და მაშინ დაბრუნების გზა გასვლის გზას არ ემთხვევა.
პასუხებმა უნდა მიაღწიონ იმავე ქვედა კლიენტს თვალთვალის მდგომარეობით ან გამოკვეთილი მარშრუტით, და გამავალი პაკეტების მთვლელი ამას არაფერს ამტკიცებს. VPN-ის საკუთარი გარე ტრანსპორტიც გამონაკლისის არეს გარეთ დაიტოვეთ, თორემ გვირაბის მატარებელი პაკეტები დაიმკვიდრებენ პოლიტიკას, რომელიც კლიენტის ვებ მოთხოვნისთვის დაიწერა.
ერთი დაჭერილი მისამართი დანიშნულება არ არის
ბრაუზერიდან წაკითხული ერთი IPv4 მისამართი მყისიერი სურათია. დიდი სერვისები პასუხობენ anycast-იდან ან კიდის მისამართების მბრუნავი ნაკრებიდან, ბევრი ორსაფეხურია, და შესვლის ნაკადმა შეიძლება შეეხოს ავთენტიფიკაციისა და ტელემეტრიის ჰოსტებს, რომლებსაც გვერდი არასოდეს აჩვენებს. თქვენს მიერ შემთხვევით ნანახი მისამართის გარშემო აგებული გამონაკლისი ტყდება მომდევნო ჯერზე, როცა სერვისი დატვირთვას გადაანაწილებს.
გამოიყენეთ სერვისის მფლობელის დოკუმენტირებული მისამართები ან მის მიერ გამოქვეყნებული დიაპაზონი და გაითვალისწინეთ მისამართების ორივე ოჯახი. თუ მოთხოვნა სტაბილურ ნაკრებად ვერ ჩამოყალიბდება, ეს, სავარაუდოდ, სერვისისთვის პოლიტიკის საკითხია და არა ტელეფონზე მარშრუტიზაციის ხრიკი.
შეამოწმეთ ქვედა მხრიდან
სამი შემოწმება, ამ თანმიმდევრობით: არჩეული სერვისი ლეპტოპიდან, ჩვეულებრივი დანიშნულება, რომელიც VPN-ის შიგნით უნდა დარჩეს, და ტელეფონის აპლიკაცია, რომელიც ხელუხლებელი უნდა დარჩეს. შემდეგ გაიმეორეთ ხელახალი დაკავშირებისა და ზედა რგოლის შეცვლის შემდეგ, რადგან სწორედ მაშინ აგებენ პოლიტიკის ცხრილებს თავიდან.
თუ ტელეფონის გაზიარების იმპლემენტაცია ვერ ინარჩუნებს ამ ხელშეკრულებას ხელახალი დაკავშირების განმავლობაში, გადაიტანეთ შერჩევითი პოლიტიკა მხარდაჭერილ ქვედა მარშრუტიზატორზე და ნუ დააგროვებთ root წესებს აპარატზე. მარშრუტიზატორს შეუძლია წყაროსა და დანიშნულების შედარება მდგრადი მფლობელით გამოხატოს, და თეთერინგის მოდულის დოკუმენტაცია არის სწორი ცნობარი იმისა, თუ რას აკეთებს ტელეფონი სინამდვილეში.