iPhone'da Always On VPN ve VPN On Demand: hangisini kurmalı

İki iPhone da VPN diyebilir ama tamamen farklı davranabilir. On Demand bir kural eşleştiğinde tünel açar ve kullanıcı bunu Ayarlar'dan yine de kapatabilir. Yönetilen Always On, tünelin kurulamadığı anlar dahil, kapsamı gözetimli bir cihazda zorunlu tutar. Kullanıcı hiçbir şey yapmadığında neyin doğru olması gerektiğini sorarak seçin, sonra kararlı durumu değil geçişleri test edin. Aşağıdaki adımlar bir dağıtımın gerçekte başarısız olduğu sırayla ilerler.

Adım 1: cihazın neyi zorunlu kılabileceğini belirleyin

Always On, gözetimli cihaz özelliğidir. Filosu gözetimli değilse tartışma başlamadan biter ve hiçbir payload anahtarı gözetimsiz bir telefonu zorunlu hale getirmez. Gözetimi yönetim tarafından ve cihazdan doğrulayın, ardından profili kimin imzaladığını doğrulayın.

Telefonda Ayarlar, ardından Genel, ardından VPN ve Cihaz Yönetimi bölümünü açın. Profil kaydı sahibini belirtir ve elle kurulan kişisel profil, bir yönetim hizmeti tarafından teslim edilenden farklı görünür. Zorunluluğu profilin adından veya sağlayıcının pazarlama etiketinden çıkarsamayın; etiket platform ilkesi değildir.

Yapılandırmaya dokunmadan önce üç gerçeği yazın: gözetimli mi değil mi, yönetilen profil mi kişisel mi ve tüneli hangi istemci uygulaması taşıyor. Sonraki her adım bu üçüne bağlıdır ve davranışı kişisel bir telefondan yönetilen profile taşımak, bir dağıtımın yanlış taban çizgisine göre onaylanmasının yoludur.

Adım 2: özelliğin adını değil on-demand kurallarını okuyun

On Demand, sırayla değerlendirilen bir kural listesidir. Her kural bir eylemi ve onu seçen koşulları belirtir; asıl ilginç kısım koşullardır: arayüz türü, Wi-Fi SSID, DNS alan adı soneki veya bir test URL'si. Hiç eşleşmeyen bir kural kümesi, hiç bağlanmayan bir özelliktir.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Dizinin tamamını okuyun ve her kural için iki soru sorun: bu koşul bu filoda hiç doğru olabilir mi ve hiçbir kural eşleşmediğinde ne olur? Kurumsal ağlar erişim noktalarını yeniden adlandırır, SSID'leri birleştirir ve DNS soneklerini değiştirir; bu düzenlemelerin her biri bir kuralı sessizce gerçeklikten koparır.

DNS soneki koşulu sahada en sık yanlış olandır, çünkü telefonun konuk ağda bildirdiği sonek kurumsal çözümleyicinin hizmet verdiği sonek değildir. Kurala güvenmeden önce cihazın gerçekten çözümlediği adı doğrulayın.

Adım 3: statik bağlantıyı değil geçişleri test edin

Siz bakarken ayakta olan bir tünel çok az şey kanıtlar. Her geçişi bilerek yapın ve cihazın ne yaptığını kaydedin; sonuçlar karşılaştırılabilir olsun diye her seferinde aynı özel kaynağı kullanın:

• Bir kuralın eşleşmesi gereken ağa bağlanın, ardından özel kaynağı isteyin ve yüklendiğini doğrulayın.
• Uygulama arka plandayken hücresel ağa geçin, sonra öne alın ve isteği yineleyin.
• Captive portal içeren bir Wi-Fi ağına bağlanın ve portala erişilebiliyor mu yoksa zorunlu tutma siz kimlik doğrulamadan her şeyi bloke mi ediyor görün.
• Gözetimli cihazda tüneli elle kapatın ve kendiliğinden geri gelip gelmediğini, ne kadar hızlı geldiğini kontrol edin.

Varsa gözetimsiz bir cihazda aynı listeyi çalıştırın. İki sonuç arasındaki fark dağıtımın gerçek davranışıdır ve bağlı bir tünelin ekran görüntüsünün asla göstermediği kısım budur.

Adım 4: iki arıza biçimini tanıyın

Zorunlu kapsam, engelleyerek başarısız olur. Tünel kurulamadığında cihaz özel kaynaklarla birlikte normal internet erişimini de kaybeder ve kullanıcı çevrimiçi ama gezinemeyen bir telefonla karşılaşır. Yeniden bağlanma ve engelleme ayrı gözlemlerdir, bu yüzden internet yok durumunu tek bir belirti saymak yerine ikisini de kaydedin.

On Demand, tetiklenmeyerek başarısız olur. Kural eşleşmez, tünel görünmez ve özel kaynak yalnızca zaman aşımına uğrar. İstemci tam olarak yapılandırıldığı gibi davrandığı için bunu sunucu sorunu olarak yanlış teşhis etmek kolaydır.

Captive portal ikisinin arasında durur: tünel var olmadan önce bağlantı gerektirir, bu yüzden tünel kurulana kadar her şeyi engelleyen bir ilkenin portal üzerinden belgelenmiş bir yola ihtiyacı vardır. Bunu tasarımda kararlaştırın, yardım masasında değil.

Adım 5: doğrulayın, sonra geri almayı prova edin

Doğrulama, zararsız trafikle gerçek yol üzerinde olmalıdır: genel olmaması gereken özel bir kaynak isteyin, cihazın dışarıya hangi adresi sunduğunu doğrulayın ve yeniden başlatmadan sonra yineleyin ki yalnızca sıcak durumu değil başlangıç dizisini de görmüş olun.

Sonra üretimde ihtiyaç duymadan önce bir test cihazında kaldırmayı prova edin. Profili kaldırmak cihazı önceki durumuna döndürür ve bunun ne kadar sürdüğünü ve kullanıcının ne gördüğünü bilmek runbook'un parçasıdır. Apple'ın VPN güvenlik kılavuzu, platformun bu ilkeler hakkında belgelediği şeyler için referanstır ve platformun söylediğinden fazlasını iddia eden bir yapılandırma yazmadan önce okumaya değer.

Birinci adımdaki üç gerçeği kural kümesinin ve test sonuçlarının yanında tutun. Sıradaki kişi telefonun neden bir ağda bağlandığını diğerinde bağlanmadığını sorduğunda, o notlar yeniden kurmak yerine bir dakikada yanıt verir.