როგორ წავიკითხოთ VPN-ისა და პროქსის მდგომარეობა მართული სამუშაო აპისთვის
მართულ ტელეფონზე VPN-ის ხატულა ძალიან ცოტას ამტკიცებს. წაიკითხეთ აქტიური ქსელი, მისი შესაძლებლობები და მოქმედი პროქსი, შემდეგ წაიკითხეთ თითოეული null ისე, როგორც არის.
სამუშაო აპი იშლება მართულ ტელეფონზე, ვიღაც ამოწმებს VPN-ის გადამრთველს, ხედავს, რომ ჩართულია და ბილიკს ჯანმრთელად აცხადებს. სწორედ აქ ჩერდება ამ დიაგნოზების უმეტესობა და ეს ძალიან ადრეა: აქტიური VPN ტრანსპორტი არ ამბობს, რომ ამ აპის მოთხოვნებმა ის გამოიყენეს, ხოლო პროქსი, რომელიც რეალურად მოქმედებს, შეიძლება იყოს აპის მიხედვით ან PAC ფაილით შერჩეული, ნაცვლად იმისა, რომ პარამეტრებში გამოჩნდეს. დაიწყეთ კონკრეტული აპით და პროფილით, რომელსაც ამუშავებთ, შემდეგ წაიკითხეთ პლატფორმის საკუთარი ხედვა ბილიკზე.
დაიწყეთ აპით და მისი პროფილით
სამუშაო ნიშნის მქონე აპი ჩვეულებრივ ცალკე პროფილში მუშაობს, საკუთარი ქსელური პოლიტიკით. იმავე ტელეფონზე პირადი ბრაუზერი მისი მტკიცებულება არ არის, და არც სხვა მართვის მქონე კოლეგის მოწყობილობის შედეგია. დააფიქსირეთ, რომელ პროფილს ეკუთვნის აპი, სანამ რამეს წაიკითხავთ.
პარამეტრებში ჩამოთვალეთ კონფიგურირებული VPN ჩანაწერები და დააფიქსირეთ, ვინ ფლობს თითოეულს. Samsung-ის ვერსიებში მენიუს ეტიკეტები გამოშვებებს შორის იცვლება, ამიტომ აღწერეთ ჩანაწერი და არა მისკენ მიმავალი ბილიკი. ნაცრისფერი ან მართული ჩანაწერი ეკუთვნის მას, ვინც მოწყობილობას მართავს; მისი გამორთვა ექსპერიმენტის სახით ცვლის იმას, რისი გაზომვაც გსურთ და შეიძლება პოლიტიკას ეწინააღმდეგებოდეს.
წაიკითხეთ მდგომარეობა, რომელსაც პლატფორმა იუწყება
თქვენი მხარდაჭერის ინსტრუმენტებში არსებული აქტივობის შიგნით, API 23 ან უფრო ახალზე, ქსელის მდგომარეობის წაკითხვა ერთი ბაიტის გაგზავნის გარეშე შეიძლება. გამოძახებას სჭირდება ჩვეულებრივი ACCESS_NETWORK_STATE მანიფესტის ნებართვა შესაძლებლობების წასაკითხად.
val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxyთითოეული მნიშვნელობა ვიწრო კითხვას პასუხობს. აქტიური ქსელი არის გამომძახებელი პროცესის ნაგულისხმევი ქსელი იმ მომენტში. შესაძლებლობების შემოწმება გეუბნებათ, არის თუ არა ეს ნაგულისხმევი ქსელი VPN-ით მხარდაჭერილი. პროქსის გამოძახება იუწყება მოქმედ ნაგულისხმევ HTTP პროქსის, და დაბრუნებული ობიექტი შეიძლება აღწერდეს სტატიკურ პროქსის ან PAC სკრიპტს.
თუ გჭირდებათ თითოეული ქსელის ხედი ნაგულისხმევის ნაცვლად, წაიკითხეთ იმავე ქსელის კავშირის თვისებები და შეადარეთ cm.getLinkProperties(network)?.httpProxy-ს. მოწყობილობის მართვის მიერ დაინსტალირებული პროქსი ჩნდება ნაგულისხმევი პროქსის გამოძახებაში და არა კავშირის თვისებებში, რაც სწრაფი გზაა პოლიტიკის მიერ მოცემული პროქსის ქსელის მიერ მოცემულისგან გასარჩევად.
შეინახეთ გამონატანი თქვენს მხარდაჭერის არხში და არა საჯარო ანგარიშში. პროქსის ჰოსტსახელები, PAC მისამართები და შიდა სუფიქსები ამხელს, როგორ მარშრუტიზებს თქვენი ორგანიზაცია ტრაფიკს, და არცერთი მათგანი არ არის საჭირო ხარვეზის აღწერისთვის.
განმარტეთ თითოეული ველი ვიწროდ
ნულოვანი ქსელი ან ნულოვანი შესაძლებლობის ობიექტი ნიშნავს, რომ გამომძახებლის ქსელის მდგომარეობა მიუწვდომელი იყო ან წაკითხვის დროს შეიცვალა. ეს არ ნიშნავს, რომ VPN არ არის. მოექეცით როგორც უცნობს და წაიკითხეთ ხელახლა მას შემდეგ, რაც აპი წინა პლანზე გამოვა, და არა როგორც უარყოფით შედეგს.
VPN ტრანსპორტი დადებითთა შორის ყველაზე სუსტია. ნებისმიერი აპი, რომელსაც VpnService აქვს, ერთს წარმოქმნის, მათ შორის ლოკალური ფილტრაციის აპი, რომელიც თქვენს ტრაფიკს არასდროს არსად აგზავნის. ასე რომ, true მნიშვნელობა ამბობს, რომ არსებობს VPN-ით მხარდაჭერილი ნაგულისხმევი ქსელი, და არა რომ თქვენი ორგანიზაციის გასასვლელი იყო გამოყენებული და რა თქმა უნდა არა რომ ინსპექცია მოხდა.
ნულოვანი ნაგულისხმევი პროქსი ნიშნავს, რომ ეს API არ იუწყება ნაგულისხმევ HTTP პროქსის მოქმედი კონფიგურაციისთვის. ის ძალიან ცოტას გამორიცხავს: აპს შეიძლება ჰქონდეს საკუთარი SOCKS პარამეტრი, დანერგოს საკუთარი HTTP კლიენტი, ან იმართოს კარიბჭის პროქსით, რომლის შესახებაც მოწყობილობა არასდროს შეიტყობს.
PAC არის ის შემთხვევა, რომელიც სძლევს ერთმნიშვნელოვან პასუხს. სკრიპტს შეუძლია ერთი დანიშნულების ადგილი პროქსით გაატაროს და მეორე პირდაპირ გაგზავნოს, ამიტომ ერთი და იმავე აპის ორი მოთხოვნა ერთი წამის განმავლობაში შეიძლება სხვადასხვა ბილიკით წავიდეს. და აპი, რომელიც თავის სოკეტებს არჩეულ ქსელზე აბავს ან იძახებს bindProcessToNetwork-ს, საერთოდ არ არის ვალდებული მიჰყვეს ნაგულისხმევს.
რასაც ეს კადრი ვერ გეტყვით
ეს ისტორია არ არის. აქ არაფერი არ იწერს, რომელი ბილიკით წავიდა წარუმატებელი მოთხოვნა, და წარუმატებლობის შემდეგ წარმატებული წაკითხვა არ არის მტკიცებულება წარუმატებლობის შესახებ. ეს არც ინვენტარია: თქვენ იღებთ გამომძახებელი პროცესის ნაგულისხმევ ქსელს და არა თითოეული აპის კერძო კავშირების სიას.
ის ასევე არაფერს ამბობს იმაზე, რაც სოკეტის ზემოთ ხდება. მართულ მოწყობილობაზე წარუმატებელი TLS ხელის ჩამორთმევა შეიძლება იყოს ნდობის საცავის პრობლემა, დამაგრების შეუთანხმებლობა ან სახელი, რომელსაც პროქსი უარყოფს, და არცერთი მათგანი არ ჩანს კავშირიანობის წაკითხვაში.
ამიტომ ორივე ნახევარი ერთად მნიშვნელოვანია: კადრი ავიწროებს, სად უნდა ვუყუროთ, და აპის საკუთარი დიაგნოსტიკა ამბობს, რა ჩავარდა სინამდვილეში.
შეატყობინეთ იმ ფორმით, რომელსაც ადმინისტრატორი გამოიყენებს
მიაწოდეთ დაზარალებული აპი, პროფილი, დროის ნიშანი და ზუსტად ის ეტაპი, რომელიც ჩავარდა: სახელის გარჩევა, TCP კავშირი, TLS ხელის ჩამორთმევა ან HTTP სტატუსი. დაამატეთ კადრის მნიშვნელობები ისე, როგორც წაიკითხეთ, ნულები დაწერილი როგორც ნულები და არა როგორც სიტყვა არაფერი. დააფიქსირეთ, ჩავარდება თუ არა სხვა აპები იმავე პროფილში იმავე გზით, რაც გამოყოფს აპის პრობლემას მთელი პროფილის ბილიკის პრობლემისგან.
შემდეგ შეჩერდით და მიეცით ბილიკის მფლობელს პასუხის გაცემის საშუალება. ნუ მიიღებთ კორპორატიულ სერტიფიკატს, პროქსის მისამართს ან VPN ჩანაწერს მართვის მოხსნის ან დამტკიცებული მარშრუტის გვერდის ავლის ნებართვად; ეს მხარდაჭერის საქმეს პოლიტიკის ინციდენტად აქცევს.
ნაგულისხმევი პროქსის ხელშეკრულება მოკლეა და ღირს ერთხელ წაკითხვად, რადგან ზუსტად განსაზღვრავს, რომელ პროქსის იუწყება გამოძახება, და ამ კადრის ყოველი გადამეტებული წაკითხვა იწყება დაშვებით, რომ ის მეტს იუწყება.