iPhone VPN-შია? რას ნამდვილად ხედავს iOS აპლიკაცია

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

ერთი VPN დროშის მითი

რწმენა ისაა, რომ SDK-ში სადღაც არის თვისება, რომელიც აცნობს, მოწყობილობა გვირაბშია თუ არა, ისე, როგორც ხელმისაწვდომობის დროშა აცნობს, ჰოსტი პასუხობს თუ არა. ასეთი საჯარო თვისება არ არსებობს. და რომც არსებობდეს, «გვირაბი არსებობს» და «ჩემი ტრაფიკი მას იყენებს» სხვადასხვა მტკიცებაა, და აპლიკაციების უმეტესობისთვის მხოლოდ მეორეს აქვს მნიშვნელობა.

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

ჩატვირთეთ პარამეტრები, სანამ nil-ს ენდობით

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

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

კავშირის ცვლილებები შეტყობინებებად მოდის

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

როცა კონფიგურაცია დაყენებულია, კავშირის მდგომარეობა გადის მოკლე მიმდევრობას: გათიშული, უკავშირდება, დაკავშირებული, ხელახლა ადასტურებს, თიშავს. «დაკავშირებული» გვირაბს აღწერს და არა მის უკან მდგომ სერვერს, ამიტომ ეს არ არის მტკიცებულება, რომ ტრაფიკი მიედინება. On-demand-ს შეუძლია გვირაბის აწევა მაშინაც, როცა აპლიკაცია შეჩერებულია, და მაშინ შეტყობინება მოდის მანამ, სანამ განსაახლებელი რამ გექნებათ.

შეზღუდული პროქსის სურათი მინიშნებაა, არა განაჩენი

CFNetwork-ს შეუძლია აპლიკაციას გადასცეს სისტემის მიმდინარე პროქსის პარამეტრები, და ამ შედეგის შიგნით არის შეზღუდული ლექსიკონი ინტერფეისის სახელზე გასაღებით. tun, utun, ppp, ipsec ან tap-ით დაწყებული სახელის დანახვა მინიშნებაა, რომ გვირაბი არსებობს. ეს რჩება სურათად იმისა, რასაც ეს აპლიკაცია ხედავს, და არა განცხადებად იმის შესახებ, სად მიემართებიან პაკეტები.

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

სიმულატორი Mac-ს სესხულობს, და სხვა აპლიკაციები უხილავი რჩება

სიმულატორს საკუთარი ქსელის დასტა არ აქვს; ყოველი კავშირი, რომელსაც ის ამყარებს, Mac-ის არის. ამიტომ ჰოსტ Mac-ზე მომუშავე VPN უკვე ძალაშია სიმულირებული აპლიკაციისთვის, და თავად სიმულატორის პარამეტრები არაფერს აჩვენებს. თუ გვირაბი სიმულატორის გაშვების შემდეგ ამოვიდა, მისი გადატვირთვა ჩვეულებრივ უფრო სწრაფია, ვიდრე აპლიკაციის გამართვა. არასტანდარტულ პორტზე მყოფ ჰოსტს სჭირდება ეს პორტი URL-ში, ან ლოკალური გადამისამართება, როგორც socat TCP-LISTEN:12345,fork TCP:host:12345.

საჯარო API-ები არ ჩამოთვლიან VPN პროფილებს, რომლებიც სხვა აპლიკაციებს ან კონფიგურაციის პროფილებს ეკუთვნის. ერთი ცნობილი აპლიკაციისთვის URL სქემის შემოწმება canOpenURL-ის მეშვეობით გადატანადი ხრიკია, და iOS 9-დან მოთხოვნილი სქემა უნდა იყოს გამოცხადებული თქვენს Info.plist-ში; თუ გამოტოვებთ, გამოძახება დააბრუნებს false-ს. OpenVPN Connect პასუხობს openvpn://-ს, რაც მას კარგ მაგალითად და ცუდ ზოგად დეტექტორად აქცევს.

გააერთიანეთ სამი დაკვირვება და თქვით, რას ნიშნავენ ისინი

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

შედეგი დაწერეთ თქვენს დიაგნოსტიკაში სამ სტრიქონად და არა ერთ boolean-ად. როცა მომხმარებელი ამბობს, რომ VPN გამორთულია, ხოლო თქვენი აპლიკაცია არ ეთანხმება, სამი სტრიქონი გვიჩვენებს, რომელი დაკვირვება გადაუხვია, და ეს არის განსხვავება მხარდაჭერის იმ ბილეთსა და მეორეს შორის, რომელიც «ჩემთან მუშაობს»-ით მთავრდება.