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

რა შეიძლება თავად აპმა შეამოწმოს

სანამ ფარულ პლატფორმულ წესს ჩათვლით, გაიხსენეთ, რომ ჩვეულებრივ აპს შეუძლია დაინახოს, აქტიურია თუ არა VPN ტრანსპორტი. ConnectivityManager აცნობებს TRANSPORT_VPN-ის მატარებელ ქსელებს და NET_CAPABILITY_NOT_VPN-ის არარსებობა ნებისმიერ გამომძახებელს ეუბნება, რომ მიმდინარე გზა გვირაბში გადის. დეველოპერს, რომელსაც გვირაბის გარეთ მუშაობაზე უარის თქმა სურს, ეს შეუძლია საჯარო API-ებით და საერთოდ საწარმოო ხელსაწყოების გარეშე.

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

სერვისის გზა: პირადი სახელები და მისამართები

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

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

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

აპის პოლიტიკის ფენა

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

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

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

პლატფორმის ფენა: მუდამ ჩართული და ბლოკირება

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

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

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

სამის გარჩევა

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

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

რა ჩავწეროთ მხარდაჭერის მოთხოვნაში

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

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

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

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