iOS VPN profili: passwordReference, parola değil

Bir profil kurarsınız, tünel ayağa kalkar ve her şey bitmiş görünür. Sonra telefon yeniden başlar, on-demand ön planda uygulama yokken bağlantıyı uyandırır ve tünel başlamayı reddeder. Profil hâlâ oradadır ve parola hâlâ doğrudur, bu yüzden bu arıza insanları yanlış yerde aramaya gönderir. Bir Network Extension sırrınızı profilden okuyamaz: kendi çözebileceği bir anahtarlık referansına ihtiyacı vardır.

Aşağıdaki anlatım, referansı kuran sorgudan onu sınayan yeniden başlatmaya kadar, bu devir teslim boyunca tek bir bağlantı denemesini izler.

Profil sırrı değil, bir tutamaç saklar

NEVPNProtocol, passwordReference ve sharedSecretReference alanlarını bir nedenle açığa çıkarır. Daemon bir tünel başlattığında sizin sürecinizin içinde çalışmıyor olabilir, bu yüzden kodunuzu çağırıp parola isteyemez. Kalıcı bir anahtarlık referansı okur, kendi bağlamında çözer ve öğeyi kendisi getirir.

Bu referansı anahtarlığa sorarak kurarsınız; bu, veri istemekten farklı bir istektir:

let query: [String: Any] = [
  kSecClass as String: kSecClassGenericPassword,
  kSecAttrService as String: "vpn-credentials",
  kSecAttrAccount as String: "user",
  kSecReturnPersistentRef as String: true,
  kSecMatchLimit as String: kSecMatchLimitOne
]

Dönen nesneyi protokole verin, öğenin verisini değil. Pratikte profil sırrın nerede yaşadığını kaydeder, bu yüzden bir yapılandırma yedeği parolayı sessizce bir plist'e kopyalamaz.

API neden -50 yanıtı verir

errSecParam, isteğin veya değerin bu işlem için bozuk biçimlendiği anlamına gelir ve referans ile veri istekleri karıştığında en sık görülen hatadır. Alıcı kod bir referans beklerken veri istemek, passwordReference alanına ham bayt atamak veya uygulamanın kullanamadığı bir erişim grubuyla sorgu yapmak, hepsi onu üretir.

Sarmalayıcı kitaplıklar buna davet eder. Bayt döndüren bir yardımcı, referans döndürenle değiştirilemez, bu yüzden onarım genellikle başka bir parola değil, başka bir sorgudur.

Aynı uyumsuzluk, şikâyet olmadan kaydedilen ve sonra bağlanmayan bir profili açıklar: saklanan şey bir blob'dur, tutamaç değil, ve daemonun çözecek bir şeyi yoktur.

İyi kaydeder, bağlanırken başarısız olur

Kaydetme uygulamanızın bağlamını çalıştırır. Bağlanma daemonun bağlamını çalıştırır ve ikisinin erişimi aynı değildir. Bu yüzden bir profil simülatörde yaptığınız her testi geçip ilk on-demand başlatmada başarısız olabilir.

Yeniden başlatma belirtisinin biçimi de budur: uygulama açıkken çalışır ve sistem tüneli kendisi başlattığında ölür.

Yayına vermeden önce arka plan yolunu bilerek test edin. Uygulama kapalıyken bir on-demand bağlantı tetikleyin, sonra uygulamanın günlüğünü değil cihaz konsolunu okuyun, çünkü arızayı referansı çözmeye çalışan süreç kaydeder. Konsol daemonun öğeyi reddettiğini gösteriyorsa referans sağlamdır ve sorun öğenin erişilebilirliğidir.

Yeniden başlatmanın işe yarayıp yaramayacağını erişilebilirlik belirler

Öğe, tüneli başlatan hangi sistem süreci olursa olsun onun tarafından okunabilmelidir ve bu, uygulamanız ön plandayken olduğundan daha geniş bir kitledir. Bu kısıtlama erişilebilirlik niteliğini sizin için seçer. İlk kilit açılışına kadar korunan bir öğe, cihaz bir kez açıldıktan sonra arka plan başlatması için kullanılabilir; cihazın şu anda açık olmasını gerektiren öğe ise kullanılamaz.

Daha katı sınıfı seçmek cezbedicidir ve kilitli bir telefonda on-demand profilini bozan tam olarak budur.

Sınıfı değiştirdikten sonra mevcut öğenin niteliklerini düzenlemek yerine öğeyi yeniden oluşturun, sonra protokolü taze bir referansla yeniden kaydedin. Mevcut bir öğedeki nitelik değişiklikleri her zaman belgelerin ima ettiği davranışı üretmez ve yeniden oluşturulmuş bir öğe kuşkuyu ortadan kaldırır.

Döndürme, kayıtlı profillerin çürüdüğü yerdir

Anahtarlıktaki parolayı değiştirmek, kayıtlı profilin neyi işaret ettiğini otomatik olarak değiştirmez. Öğeyi silmek daha kötüdür: profil artık var olmayan bir şeye referans tutar ve arıza bir kimlik doğrulama reddi gibi görünür.

Tek bir sırayla döndürün. Öğeyi güncelleyin, yeni bir kalıcı referans sorgulayın, protokolü yeniden kaydedin, sonra uygulama kapalıyken bağlanarak daemonun onu hâlâ çözebildiğini kanıtlayın. Kullanıcı parolasını ve paylaşılan sırrı ayrı öğelerde tutun ki her biri kendi takvimine göre dönsün ve sorgu sözlüğünü ya da referansın kendisini asla günlüğe yazmayın. Tutamaç bir sır değildir, ama ona giden bir haritadır.