როგორ შევამოწმოთ VPN-ის სტატუსი ping-ის გარეშე Android-ზე, iOS-ზე და Windows-ზე

ping მხოლოდ იმას ამტკიცებს, რომ ერთმა ჰოსტმა უპასუხა, და არა იმას, რომ გვირაბი აქტიურია. ჰკითხეთ Android-ის, iOS-ისა და Windows-ის სტატუსის API-ებს, შემდეგ კი შეამოწმეთ ის მარშრუტი, რომელიც თქვენს აპს ნამდვილად სჭირდება.

192.0.2.10-ის ping-ი მხოლოდ იმას გეუბნებათ, რომ ერთმა მისამართმა ICMP ექოს უპასუხა, და მეტს არაფერს. გვირაბის გარეშე ქსელში ის მაინც შეიძლება წარმატებული იყოს, რადგან მისამართი შეიძლება ლოკალურ ქვექსელში იყოს; ჯანსაღი გვირაბით ის შეიძლება ჩავარდეს, რადგან სერვერი ICMP-ს ყრის, სანამ HTTPS-ს ემსახურება. შემოწმება, რომელიც თქვენს სკრიპტს სჭირდება, არის პლატფორმის სტატუსის მოთხოვნა პლუს მარშრუტის ტესტი იმ დანიშნულებისკენ, რომელსაც აპლიკაცია იყენებს. მათ ორ ცალკე ველად მოეპყარით, არასდროს ერთ ბულევანად.

რას ამტკიცებს სინამდვილეში ექოს პასუხი

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

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

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

ჰკითხეთ Android-ს ტრანსპორტის შესახებ, და არა ping-ის

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

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

ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

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

iOS: ინტერფეისის სახელები ევრისტიკაა, არა კონტრაქტი

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

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

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

let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
    let up = manager.connection.status == .connected
    print(up)
}

პლატფორმის სტატუსის დროშა მაინც არ ამტკიცებს, რომ ტრაფიკი პარტნიორამდე აღწევს. სწორედ ამ ცარიელ ადგილს ფარავს მარშრუტის ტესტი, და ამიტომ ერთი ბულევანი საკმარისი არ არის მხარდაჭერისთვის.

Windows-ის პროფილები ხსნიან ნამდვილ სტატუსის ველს

Windows VPN პროფილებს ადაპტერებისგან ცალკე თვალს ადევნებს, და Get-VpnConnection ავლენს ConnectionStatus-ს ყოველი პროფილისთვის, რომელიც მან იცის. Windows კლიენტით ან უზრუნველყოფის პაკეტით შექმნილი პროფილები აქ ჩნდება. Cmdlet არ არის გვირაბის ზოგადი დეტექტორი.

წაიკითხეთ ველი დასახელებული პროფილისთვის, დაამატეთ -AllUserConnection, როცა პროფილი ყველა მომხმარებელს ეკუთვნის:

Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress

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

სტატუსი პლუს მარშრუტი: ორნაწილიანი შემოწმება

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

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

ip route get 192.0.2.10
resolvectl query intranet.example.test

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

ტესტი, რომლის თანმიმდევრობით გაშვებაც შეგიძლიათ

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

dig-ისა და curl-ის მქონე Linux მანქანაზე სამი ბრძანება ფარავს გადაწყვეტას, მარშრუტს და თავად სერვისს. გაუშვით ისინი გვირაბის აწეული მდგომარეობით და კვლავ ჩამოშვებულით:

dig +short intranet.example.test
ip route get 198.51.100.20
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 https://intranet.example.test/health

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

დაკავშირებული სტატიები