აპლიკაციაზე დაფუძნებული VPN მართვად iPhone-აპებზე: რა იმარშრუტება და რა არა
აპლიკაციაზე დაფუძნებული გვირაბი მართვად აპს მიჰყვება, არა ტელეფონს. შეამოწმეთ დატვირთვის კავშირი, მართვადი ასლი, მოთხოვნით გაშვების წესები და აპიდან გამომავალი ნაკადები.
iPhone-ზე აპლიკაციაზე დაფუძნებული VPN მთელი ტელეფონის გადამრთველი არ არის. ეს არის კავშირი ერთ მართვად აპსა და ერთ VPN დატვირთვას შორის, რომელიც აპის განლაგებისას იქმნება, და დანარჩენი ყველაფრის ტრაფიკი ძველ მარშრუტს ინარჩუნებს. ამიტომ იგივე ტელეფონი არათანმიმდევრულად იქცევა: სამუშაო აპი პირად გვერდს ხსნის, მაშინ როცა Safari იმავე ჰოსტს ვერ აღწევს, ან გვირაბი საერთოდ არ ადის და აპი დროის ამოწურვას აცხადებს, რაც ცუდ სერთიფიკატებს ჰგავს. შემოწმებები ყველაზე ფართო მიზეზიდან ქვევით მიდის, ამიტომ გაჩერდით პირველ წარუმატებელზე.
ჯერ შეამოწმეთ დატვირთვა და აპის ჩანაწერი
კავშირი ორ ობიექტში ცხოვრობს და არა ერთში. VPN დატვირთვა განსაზღვრავს გვირაბს: ტიპი, სერვერი, ავთენტიფიკაცია, DNS და პროვაიდერის პაკეტის იდენტიფიკატორი, როცა მორგებული კლიენტი გამოიყენება. აპის ჩანაწერი ამ დატვირთვაზე მიუთითებს, და მართვის კონსოლების უმეტესობა ამას აპის კონფიგურაციაში აპლიკაციაზე დაფუძნებულ ვარიანტად გვთავაზობს, Per-App VPN-თან ახლო სახელით. დატვირთვა, რომელზეც არც ერთი აპი არ მიუთითებს, აპლიკაციაზე დაფუძნებულად არაფერს მარშრუტავს; ის ჩვეულებრივი გვირაბივით იქცევა, რომელიც ვინმემ ხელით უნდა გაუშვას.
წაიკითხეთ ორივე ობიექტი ტელეფონზე შეხებამდე. დარწმუნდით, რომ აპის კონფიგურაცია მიუთითებს თქვენს საცდელ დატვირთვაზე და არა მის ძველ ასლზე, რადგან მიგრაციის შემდეგ თითქმის იდენტური სახელების დუბლირებული დატვირთვები ჩვეულებრივია და აპი სიამოვნებით მიუთითებს გაუქმებულზე. შემდეგ დარწმუნდით, რომ კონფიგურაცია მოწყობილობამდე მივიდა: პარამეტრები, ზოგადი, VPN და მოწყობილობის მართვა უნდა აჩვენებდეს მას დაყენებულ პროფილად. იქაური VPN სია გამოცდა არ არის. აპლიკაციაზე დაფუძნებულ სერვისს ჩვეულებრივ ხელის გადამრთველი არ აქვს, ამიტომ სწორად განლაგებული კონფიგურაცია შეიძლება არასდროს გამოჩნდეს გასაშვებ VPN-ებს შორის. არყოფნა ჩანს აპის ჩანაწერში და იმაში, ადის თუ არა გვირაბი აპის პირველ მოთხოვნაზე.
ერთი პირობა ბევრ ბილეთს ხსნის: ეს მოდელი მოითხოვს, რომ აპი მართვის გავლით მოვიდეს. გვერდიდან დაყენებული ან პირადად ნაყიდი ასლი კავშირს არ იღებს, თუნდაც მისი პაკეტის იდენტიფიკატორი ემთხვეოდეს. Apple-ის VPN განლაგების სახელმძღვანელო აღწერს ამის უკან მდგარ დატვირთვის მოდელს (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
დარწმუნდით, რომ დაყენებული აპი მართვადი ასლია
კავშირი მიჰყვება დაყენებულ, მართვად აპს. თუ ვინმემ ის ხელახლა დააყენა App Store-იდან პირადი Apple ID-ით, შეცვალა ხელახლა ხელმოწერილი კორპორატიული ნაგებობით, ან მოწყობილობა ხელახლა დარეგისტრირდა და აპი სხვა არხით დაბრუნდა, გვირაბი შეიძლება ქვემოთ დარჩეს, სანამ თავად აპი სრულიად ნორმალურად გამოიყურება.
სცადეთ შედარებით და არა ერთი დაკვირვებით. მართვის ინვენტარში აპი უნდა ჩანდეს როგორც მართვადი ამ მოწყობილობისთვის, VPN რუკებით მის ჩანაწერში. ტელეფონზე გვირაბი უნდა ავიდეს აპის გაშვებისას და მისი პირველი მოთხოვნის გასვლისას, და არა მხოლოდ მაშინ, როცა ვინმე პარამეტრებში ცალკე ხელის კონფიგურაციას უშვებს. თუ აპის გაშვება არაფერს ცვლის, ხოლო ეს ხელის კონფიგურაცია ცვლის, აპი საერთოდ არ არის დაკავშირებული აპლიკაციაზე დაფუძნებულ გვირაბთან.
განახლებებს მნიშვნელობა აქვს: მართვის გავლით გაგზავნილი ინარჩუნებს რუკებს, ხოლო მომხმარებლის მიერ დაწყებულმა ხელახალმა დაყენებამ შეიძლება დაკარგოს ის. როცა საჩივარი განახლებიდან ითვლის დროს, ქსელამდე შეამოწმეთ აპის ჩანაწერი.
შეამოწმეთ, რისი აღება შეუძლია გვირაბს
აპლიკაციაზე დაფუძნებული გვირაბი აირჩევა წყარო აპით, ამიტომ ტელეფონის ნაგულისხმევი მარშრუტი კვლავ Wi-Fi-ს ან მობილურ ქსელს ეკუთვნის. OverridePrimary არის გასაღები, რომელიც ამას ცვლის. როცა პროფილი მას აყენებს, გვირაბი სრული გვირაბივით იქცევა და ყველა აპი მემკვიდრეობით იღებს მას, ამიტომ VPN-ზე გამავალი ყველაფერი აპის უკმარისობის ნაცვლად პროფილის საკითხი ხდება.
მოთხოვნით გაშვების წესები წყვეტენ გამძლეობას. OnDemandEnabled და მისი წესების ნაკრები აბრუნებს გვირაბს, როცა აპი ტრაფიკს აგზავნის, უძლებს Wi-Fi-დან მობილურ ქსელზე გადასვლას, ან ეცემა, როცა აპი ფონზე გადადის. განლაგებას, რომელიც უერთდება და შემდეგ ჩუმად კვდება, ჩვეულებრივ აქვს წესი, რომელიც მხოლოდ ზონდს ემთხვევა და არასდროს აქტიურდება, სანამ აპი უმოქმედოა.
შემდეგ წაიკითხეთ მარშრუტების მხარე პატიოსნად. თუ პროვაიდერის ან გამყიდველის პროფილი მოცემს ჩართვის სიას, მხოლოდ 10.20.0.0/16-ის მატარებელი გვირაბი არ გადაიტანს სერვისს 10.30.0.0/16-ში; სია ასრულებს თავის საქმეს და ეს აპლიკაციაზე დაფუძნებული უკმარისობა არ არის. ჩაშენებულ iOS დატვირთვას ჩართვის სია არ აქვს. მის გარეშე დაყოფა მიჰყვება პროვაიდერის ნაგულისხმევებს და IncludeAllNetworks-ს და არა დამალულ სიას.
სცადეთ აპი, შემდეგ სცადეთ, რაც მისგან გადის
სცადეთ სახელით და არა მხოლოდ მისამართით. შიდა ჰოსტის ამოხსნა მართვადი აპის შიგნით ამტკიცებს, რომ DNS-იც გვირაბზე გავიდა, რადგან დატვირთვა წყვეტს, რომელი ამომხსნელი გასცემს პასუხს და რომელი საძიებო დომენები გამოიყენება. მარშრუტიზაცია შეიძლება სრულყოფილი იყოს, სანამ სახელის ძებნა ვარდება, და ორი სიმპტომი სხვადასხვა პარამეტრზე მიუთითებს.
შემდეგ სცადეთ საზღვარი ორივე მხრიდან. პირადმა აპმა ან Safari-მ უნდა მიაღწიოს ჩვეულებრივ საჯარო გვერდს და მიუთითოს ოპერატორის ან სახლის მისამართი, ხოლო მართვადი აპი აღწევს პირად სერვისს. თუ ორივე ერთსა და იმავე საჯარო მისამართს აცხადებს, გვირაბი აღარ არის აპლიკაციაზე დაფუძნებული, რასაც არ უნდა ამტკიცებდეს აპის ჩანაწერი.
აპიდან გამომავალი ნაკადები ქმნიან დამაბნეველ ბილეთებს. ბმული, რომელიც Safari-ში იხსნება, გაზიარების ფურცლით გადაცემული დოკუმენტი ან ბრაუზერზე გადასული SSO შესვლა ტოვებს აპის პროცესს და მასთან ერთად გვირაბს. აპის შიგნით ნაჩვენები შესვლა ჩვეულებრივ აპს მიეკუთვნება, ამიტომ ჩაშენებული შესვლა შეიძლება წარმატებული იყოს იქ, სადაც იგივე URL Safari-ში ვარდება; ეს გადაამოწმეთ და ნუ ჩათვლით. როცა იდენტობის პროვაიდერი მხოლოდ გვირაბით არის ხელმისაწვდომი, ან შესვლა აპის შიგნით შეინარჩუნეთ, ან პროვაიდერის დომენი დაამატეთ დატვირთვის Safari დომენებს, რათა შესაბამისი Safari ტრაფიკი დაიჭიროს.
შეუსაბამეთ სიმპტომი შრეს
უკმარისობის ფორმა გეუბნებათ, რომელი შემოწმება გაიმეოროთ.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
შუა რიგების უკან ორი დეტალია: აპლიკაციაზე დაფუძნებული გვირაბი შეიძლება ჯანმრთელი იყოს და მაინც გამოტოვოს ქვექსელი, რომელსაც არც ერთი პროვაიდერის სია არ მოიცავს, და მართვად ტელეფონს შეიძლება ერთზე მეტი VPN კონფიგურაცია ჰქონდეს, ამიტომ დაადასტურეთ, რომელზეა აპი მიბმული, ნაცვლად იმისა, რომ ჩათვალოთ, რომ ეს თქვენს მიერ წაკითხულია.
გაასწორეთ ამ თანმიმდევრობით: გაასწორეთ აპის ჩანაწერი, რომ მიუთითებდეს ცოცხალ დატვირთვაზე, გადააყენეთ აპი მართვის გავლით, დაადასტურეთ, რომ გვირაბი აპის პირველ მოთხოვნაზე ავა, შემდეგ გაიმეორეთ სახელისა და საზღვრის გამოცდები. თუ პირველი მოთხოვნა საერთოდ ვერ უშვებს გვირაბს, გაჩერდით და შეამოწმეთ პროვაიდერის მხარე, რადგან მორგებულ კლიენტს სჭირდება Network Extension-ის არსებობა და დაყენებული აპის შესაბამისი იდენტიფიკატორი.
დააბრუნეთ სამი ფაქტი ეკრანის სურათის ნაცვლად: რომელ დატვირთვაზე მიუთითებს აპის ჩანაწერი, აჩვენებს თუ არა პარამეტრები მას დაყენებულ პროფილად და რა იყო წარუმატებელი მოთხოვნა, სახელი, მისამართი თუ ბრაუზერზე გადაცემა. ეს სამი პასუხი განასხვავებს განლაგების შეცდომას მარშრუტიზაციის შეცდომისგან და შემდეგი ადამიანი დიაგნოზის გამეორების გარეშე იმოქმედებს.