iOS için VPN API'leri: NEVPNManager, tünel sağlayıcı mı profil mi?
API'yi konuşmanız gereken taşımaya göre seçin, ardından tünelin trafiği taşıdığını kanıtlayın: save-load-start sırası, provider entitlement'ları ve on-demand kuralları.
iOS VPN adına üç farklı ürün yanıt veriyor ve tek bir API paylaşmıyorlar. Personal VPN sistemin yerleşik IPsec ve IKEv2 taşımalarını kullanır. Custom tunnel kendi protokolünüzü bir network extension içinde çalıştırır. Configuration profile ikisinden birini yapılandırır ve on-demand davranışı ekleyebilir. Konuşmanız gereken taşımaya göre seçmek, ilk derlenen öğreticiye göre seçmekten daha hızlıdır.
Aşağıdaki kontrolleri sırayla çalıştırın, çünkü her adım öncekinin geçerli bir yapılandırma ürettiğini varsayar.
Adım 1: taşımaya göre seçin
Sunucu IKEv2 veya Cisco tarzı IPsec ise NEVPNManager yeterlidir ve sistem taşımaları bedava gelir. Sunucu OpenVPN, WireGuard veya başka bir şey konuşuyorsa NEVPNManager yardımcı olamaz: üçüncü taraf bir protokol için kancası yoktur. Bu durum protokolü uygulayan bir packet tunnel provider ile NETunnelProviderManager gerektirir. Profil yalnızca yapılandırma dağıtır ve işletim sisteminde olmayan bir taşımayı ekleyemez.
PPTP güncel sistemlerde hedef değildir. Paylaşılan sırlı IPsec hâlâ remoteIdentifier içinde grup adını, sırrı tutan bir keychain öğesini ve sunucu kullanıcı adı istediğinde genişletilmiş kimlik doğrulamayı bekler. Eksik her parça aynı genel yapılandırma hatası olarak görünür, bu yüzden başka bir şeyi ayıklamadan önce hepsini ekleyin.
Adım 2: kaydet, yükle, başlat sırasına uyun
NEVPNManager preferences dosyasına yazar, geri okur ve ancak ondan sonra başlatır. Protokol ve manager nesnelerini doldurun, saveToPreferences çağırın, loadFromPreferences çağırın ve load completion handler içinden startVPNTunnel çağırın. Yükleme dönmeden başlatmak, aksi hâlde doğru olan bir yapılandırmada configuration-invalid hatası, NEVPNErrorDomain code 1, üretir.
Biçim tek bir yerde tutulacak kadar kısa:
manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }startVPNTunnel istek kabul edildiğinde döner, tünel ayaktayken değil. NEVPNStatusDidChange'i izleyin ve gerçek durum için connection.status okuyun. Çağrı noktasında başarı varsayan bir uygulama extension hâlâ pazarlık ederken VPN bağlı diye bildirir. Connecting durumu bir an için normaldir; hiç terk etmeyen durum, günlüğe yazılmaya değer arızadır.
Adım 3: provider sürecine ihtiyacı olanı verin
Custom transport kendi bundle identifier'ı ve kendi entitlement'ı olan ayrı bir süreçte çalışır. Hem container uygulaması hem de provider imzalama sırasında network-extension entitlement'ına ihtiyaç duyar ve App Store dışındaki bir Developer ID derlemesi onu yine de provisioning profile içinde taşımalıdır. Eksik entitlement protokol hatası gibi görünür çünkü extension başlamaz.
Ödünç alınacak herkese açık bir socket descriptor yoktur. NEPacketTunnelProvider size read, write ve cancel içeren NEPacketTunnelFlow verir ve özel anahtar yollarına uzanan kod sürümler arasında kırılır. Uygulama arka plandayken provider çalışmaya devam eder, bu yüzden container uygulamasının bunun için arka plan moduna ihtiyacı yoktur.
Adım 4: on-demand bir kural kümesidir, anahtar değil
isOnDemandEnabled yalnızca kuralları silahlandırır; tünelin ne zaman kalkacağına NEOnDemandRuleConnect ve kardeşleri karar verir. probe URL içeren bir evaluate-connection kuralı ancak o URL kadar iyidir. Probe tünel olmadan yanıt verirse kural özel ağın zaten erişilebilir olduğu sonucuna varır ve asla bağlanmaz, bu yüzden onu yalnızca içeriden yanıt veren bir şeye yönlendirin.
Always-on ayrı bir vaattir. Denetlenen bir cihaz ve yönetilen bir profil gerektirir ve denetlenmeyen bir kullanıcı profili istediği zaman kaldırabilir. Filosu denetlenmedikçe always-on'a bağlı bir tasarımı yayınlamayın.
Adım 5: etiketi değil, yolu kanıtlayın
tun, tap, ppp veya ipsec arayüzlerini taramak bir VPN'in yapılandırıldığını kanıtlar, isteğinizin onu kullandığını değil. usesInterfaceType(.other) ile NWPathMonitor sanal bir arayüzün kullanılabilir olduğunu söyler ve bir viability handler tek bir ana bilgisayarı test edebilir. İkisi de çıkış yolunu kanıtlamaz, bu yüzden onları yalnızca tünelin ulaşabildiği bir kaynağa yapılan istekle birleştirin. Arayüz adları tanılama yardımcısıdır, uygulama mantığının dallanacağı bir kapı asla değildir.
Saha kontrolü için genel adresi tünelle ve tünelsiz karşılaştırın ve yalnızca dahili bir sayfa getirin. Bir status çağrısı provider pazarlık ederken bağlı diye bildirebilir, bu yüzden kararı kaynağın sonucu versin ve status'u destekleyici kanıt olarak ele alın.