NEVPNManager არ ინახავს? თანმიმდევრობაა: ჩატვირთვა, ჩართვა, შენახვა, დაკავშირება

ორი შეცდომის კოდი ხსნის iOS-ზე Network Extension VPN-ის პირველი ცდების უმეტესობას: NEVPNErrorDomain Code=4 და Code=5. არც ერთი მათგანი სერვერის ჩივილი არ არის. ერთი ჩნდება მაშინ, როცა აპი პარამეტრებს წერს ობიექტში, რომელიც არასდროს წაკითხულა დისკიდან, მეორე კი მაშინ, როცა თავად ჩაწერა ვერ ხერხდება, ყველაზე ხშირად იმიტომ, რომ პროფილი ინახება ჯერ კიდევ გამორთულ მდგომარეობაში. ორივე სწორდება ოთხი გამოძახების თანმიმდევრობის შეცვლით და არა IKEv2 პარამეტრებთან შეხებით.

ჯერ ჩატვირთეთ, თორემ შენახვას შესადარებელი არაფერი აქვს

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

let mgr = NEVPNManager.shared()
mgr.loadFromPreferences { loadErr in
    guard loadErr == nil else { return }
    let proto = NEVPNProtocolIKEv2()
    proto.serverAddress = "vpn.example.net"
    proto.username = "alice"
    proto.useExtendedAuthentication = true
    mgr.protocolConfiguration = proto
    mgr.isEnabled = true
    mgr.saveToPreferences { saveErr in
        // do not start here; reload, then connect
    }
}

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

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

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

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

მესამე მხარის აპებისთვის მხოლოდ ორი პროტოკოლია ხელმისაწვდომი

Network Extension აძლევს აპებს IPsec-ს და IKEv2-ს. L2TP და PPTP სისტემის შიგნით რჩება, ამიტომ აპი, რომელსაც ისინი სჭირდება, ვერ მიიღებს მათ, და რეალისტური პასუხებია IKEv2-ს მხარდამჭერი კარიბჭე ან მართული კონფიგურაციის პროფილი.

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

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

გამორიცხეთ უფლება სანამ კოდს გადაწერთ

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

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

დააკვირდით მდგომარეობის ცვლილებებს და არა ვარაუდებს

დააკვირდით NEVPNStatusDidChangeNotification-ს და ყოველი ნაბიჯის შემდეგ ჩაწერეთ manager.connection.status. მდგომარეობა, რომელიც არასდროს ტოვებს invalid-ს, ნიშნავს, რომ პროფილი არ შეინახა ან უფლება არ არის. კავშირი, რომელიც connecting-ს აღწევს და არასდროს უკავშირდება, მიუთითებს წინადადებაზე ან სერტიფიკატებზე, რაც სხვა მტკიცებულებებით სხვა გამოძიებაა.

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