iPhone'da VPN uygulaması mı yerleşik IKEv2 mi: nasıl seçilir
Bir iPhone VPN uygulaması ile yerleşik IKEv2 istemcisi farklı sorunları çözer. Önce protokol desteğini, kimlik doğrulamayı, cihaz denetimini ve kurtarmayı karşılaştırın.
Geçen hafta bir meslektaşım iPhone'unu uzattı; Ayarlar'da iki VPN girdisi vardı: birini sağlayıcı uygulaması bırakmıştı, diğeri bir destek sayfasından yapıştırılan IKEv2 profilindendi. Bunlar aynı şeyin rakip sürümleri değil. Sağlayıcı uygulaması kendi tünel kodunu taşıyabilen bir kapsayıcıdır; Apple'ın yerleşik istemcisi ise elle veya profille yapılandırılan bir IKEv2 istemcisidir. Protokol, kimlik bilgilerinin işlenmesi, cihaz denetimi ve kurtarma seçimi belirler.
Uygulama ile yerleşik istemci farklı katmanlarda durur
Apple'ın yerleşik VPN istemcisi pratikte bir IKEv2 istemcisidir. Elle doldurulan form hâlâ kullanımdan kalkmış IPsec üzerinden L2TP ve Cisco IPsec seçeneklerini listeler, ancak sağlayıcı taşıması için alan ve OpenVPN ya da WireGuard yapılandırması yapıştırılacak yer yoktur. Ya Ayarlar > Genel > VPN & Cihaz Yönetimi altında form doldurursunuz ya da VPN yükü taşıyan bir profil içe aktarırsınız; yüzey sunucu adresi, iki kimlik, bir kimlik doğrulama yöntemi ve isteğe bağlı talep üzerine kurallardır.
Sağlayıcı uygulaması bir katman yukarıda çalışır. Bir Network Extension paket tüneli sağlayıcısı sunar, böylece protokol kodu ve yönlendirme mantığı uygulamada yaşar, iOS yalnızca paketleri geçirir. Bazı uygulamalar WireGuard ya da OpenVPN uygular, bazıları kendi gizlenmiş taşımasını, birkaçı ise yalnızca bir IKEv2 profili kurup yerleşik istemciyi daha hoş bir ekranın arkasından yönetir. Son grup yüzünden uygulama mı profil mi seçimi bazen yanıltıcıdır.
Sonuç pratiktir: bir .ovpn ya da WireGuard dosyası bu alanların yerini tutmaz, çünkü el sıkışma başka bir protokoldür.
Özellikleri karşılaştırmadan önce yükü okuyun
Profil IKEv2 olduğunda, yük anahtarları herhangi bir özellik karşılaştırmasından çok daha fazla arızayı açıklar. Apple'ın IKEv2 ayarları başvurusu her anahtarı belgeler; kısaltılmış bir yük şöyle görünür:
<key>VPNType</key><string>IKEv2</string>
<key>RemoteAddress</key><string>vpn.example.net</string>
<key>RemoteIdentifier</key><string>vpn.example.net</string>
<key>LocalIdentifier</key><string>[email protected]</string>
<key>AuthenticationMethod</key><string>Certificate</string>
<key>ServerCertificateIssuerCommonName</key><string>Example Issuing CA</string>
Üç alan tanılama ağırlığının çoğunu taşır. RemoteIdentifier istemcinin sunucudan sunmasını beklediği addır, bu yüzden NAT arkasındaki bir ağ geçidi veya sertifikası adres yerine havuzu adlandıran bir yük dengeleyici, adres doğru olsa bile başarısız olur. LocalIdentifier sunucunun sizi sandığı kimliktir ve sertifikayla kimlik doğrulamada hesabınıza eşlenen kimlikle eşleşmelidir. ServerCertificateIssuerCommonName veren CA'yı sabitler, bu yüzden bir profil sertifikanın yeniden verildiği gün başarısız olabilir ve hiçbir hata mesajı sertifikalardan söz etmez.
Eğer AuthenticationMethod SharedSecret ise, sunucu EAP kullanıcı kimlik doğrulaması yapıyordur ve size verilen sır aslında bir hesap kimlik bilgisidir. Bu, bir sağlayıcı iki belge gönderdiğinde önemlidir: biri kullanıcı adı ve parola için, diğeri bir sertifika için, ve yalnızca biri içe aktardığınızla eşleşir.
Uygulamanın yapabildiği, yerleşik istemcinin yapamadığı şeyler
Protokol seçimi bariz avantajdır. Sunucunuz WireGuard ya da OpenVPN konuşuyorsa, uygulama bunu kullanabilen tek iOS istemcisidir ve yerleşik formu düzenlemek bunu müzakere etmez. Bir uygulama ayrıca hedefe veya uygulamaya göre bölünmüş tünel, kendi DNS işleyişi, kill switch tarzı engelleme, sunucu seçimi ve kendi ağına göre ayarlanmış yeniden bağlanma uygulayabilir.
Bedel, denetlemediğiniz yazılımın bir ağ uzantısının ayrıcalıklarıyla çalışmasıdır. Kalite mağaza kartlarının ima ettiğinden daha çok değişir: bir uygulama temiz yeniden bağlanırken bir diğeri ağ değişikliğinden sonra birkaç saniye sızdırır ve uygulama içindeki kill switch o uygulamanın özelliğidir, iOS'un değil. Yönetilen bir cihazda önce onaylı listeyi kontrol edin.
Yerleşik IKEv2 profilinin doğru yaptığı şeyler
Daha az hareketli parça tüm argümandır. IKEv2 istemcisi ve IPsec yığını işletim sistemiyle gelir, bu yüzden çökebilecek bir uzantı, her uygulama için canlı tutulması gereken bir süreç ve sizinle çalışan bir tünel arasında üçüncü taraf güncelleme döngüsü yoktur. Bir profil ayrıca kilitlenebilir: gözetimli bir cihazda kullanıcı yönetimin kurduğunu kaldıramaz ve kullanıcı anahtarı olmadan her ağda yeniden bağlanan Always On VPN yalnızca bu gözetimli, profille yönetilen biçimde var olur.
Yerleşik yolun vermediği şey esnekliktir. Yönetilen uygulamalar olmadan uygulama başına VPN yok, kullanıcıya dönük kill switch yok ve IPsec'i engelleyen bir ağda HTTPS gibi görünen bir taşıma yok. UDP 500 ve 4500'ü düşüren otel ağlarında yerleşik IKEv2'nin yedeği yoktur.
Çoğu durumu çözen bir karar tablosu
Pratikte protokol sorusu, özellikler önem kazanmadan önce çoğu durumu çözer.
| What you were given | Device situation | What to use |
|---|---|---|
| An .ovpn or WireGuard config | Personal phone | Provider app; the native form cannot load it |
| IKEv2 host plus CA name | Personal or managed | Profile, or the app's own IKEv2 mode |
| IKEv2 with username and secret | Personal phone | Either; the profile is simpler if you never switch servers |
| A management-installed profile | Supervised, MDM | Native client; do not add a second app entry |
| A per-app tunnelling requirement | Personal phone | App, or accept a full tunnel; iOS cannot split by app without management |
| IPsec blocked on your main network | Any | App with a transport that survives the block |
İki satır ikinci bir bakışı hak ediyor. Kişisel telefonda uygulama başına gereksinim, insanların yanlış okuduğu durumdur: ayar iOS'ta vardır ama yönetim tarafından yönlendirilir, bu yüzden yönetilmeyen bir cihaz bunu sunmaz. Engellenen bir ağ IKEv2'ye güvenmemek için neden değildir; sağlayıcının uygulamasının var olmasının nedenidir.
Seçimi tek bir testle doğrulayın
Bağlan düğmesini değil, arıza biçimlerini test edin. Bir kez bağlanın, VPN göstergesinin göründüğünü doğrulayın, sonra genel adresinizi geri döndüren bir sayfa açıp öncekiyle karşılaştırın. VPN'e dokunmadan Wi-Fi'dan hücresel veriye geçin ve yeniden bağlanmayı izleyin, ardından telefonu uçak modundan geçirin. Yeniden başlatın ve tünelin kendi kendine dönüp dönmediğine bakın: OnDemandEnabled içeren bir profil dönmelidir, oysa birçok uygulamanın önce açılması gerekir.
Dönmediğinde, arızayı bir tünelin olup olmadığına göre ayırın. VPN göstergesi yoksa tünel hiç kalkmamıştır: ya el sıkışma RemoteIdentifier, sabitlenmiş CA ya da bir kimlik bilgisinde başarısız oldu, ya da bağlantı hiç denenmedi çünkü talep üzerine kural eşleşmedi ve hiçbir uygulama onu başlatmadı. Gösterge var ama trafik başarısızsa bu yönlendirme, DNS veya sunucu tarafı ilkesidir ve istemciyi yeniden kurmak bunların hiçbirine dokunmaz.
Cihazı bir sonraki kişiye açıklanabilir bırakmak için kısa bir liste:
- bir VPN girdisi, iki değil;
- profil veya uygulama, bağlandığı sunucunun adıyla adlandırılmış;
- kimlik değerleri bulabileceğiniz bir yere yazılmış.
Tablodaki protokol satırıyla başlayın ve soruyu yanıtlıyorsa orada durun.