Tek bir masaüstünde çalışan profil, tek bir istemcinin başarılı testidir. Bu, platformlar arası bir dağıtım değildir ve böyle davranmak tanıdık destek desenini üretir: Windows bağlanır, telefon kimlik denetiminde başarısız olur ve yönetilen dizüstü her uyandığında yeniden bağlanır. Farklar gerçektir ve çoğunlukla öngörülebilirdir; bu yüzden plan bir ekran görüntüsü değil, matris olmalıdır.

Önce kimlik sözleşmesine karar verin

Algoritmaları tartışmadan önce sunucu kimliğini, sertifika güvenini ve istemci kimlik doğrulama yöntemini belgeleyin. Bu üçü, bir istemcinin kimlik doğrulayıp doğrulayamayacağına karar verir ve platformların farklı ifade ettiği parçalar tam olarak bunlardır.

Her platformun beklenen tanımlayıcıyı nasıl adlandırdığını ve özne alternatif adlarını nasıl ele aldığını kontrol edin. Bir istemcide sunucu adını kabul eden profil, tanımlayıcı alanı farklı bir değerle doldurulduğu için aynı sertifikayı diğerinde reddedebilir.

Contract elementWhat to decideWhere platforms diverge
Server identityName or address the client must seeIdentifier field and SAN matching
Client authenticationCertificate, EAP method or bothWhich EAP variants exist and how prompts appear
Trust anchorWhich CA and how it is deliveredStore location and provisioning path

Ardından kriptografik kesişimi seçin

Desteklenen her istemcinin sunabileceği teklifleri karşılaştırın ve ağ geçidinin de izin verdiği modern bir kesişim seçin. Tek bir eski cihaz bağlanabilsin diye aşırı büyük bir eski liste etkinleştirmeyin, çünkü o liste sonradan gelen herkes için ağ geçidinin varsayılanı olur. Her eski seçeneğin neden hâlâ orada olduğunu yazın. İhtiyaç duyan cihazı kimse adlandıramıyorsa bu bir gereksinim değildir.

Planda IKE ve CHILD ayarlarını ayrı tutun. IKE değişimi için kabul edilebilir bir teklif, korumalı trafik için otomatik olarak kabul edilebilir değildir ve ikisi ayrı ayrı müzakere edilir. Teklifi bir katmanda kabul eden bir ağ geçidi, diğer katmanda yine de reddedebilir ve günlük, ilk katman başarılı olmuş gibi görünen bir hata gösterir.

Kimlik bilgilerini doğrulanmış bir süreçle sağlayın ve kullanıcı parolasını, paylaşılan sırrı ve istemcinin özel anahtarını kendi alanlarında tutun. Benzer adlı kutularda deneme yanılma, çalışan bir testi yeniden üretilemez hâle getiren yoldur.

Kararlı durumu değil, yaşam döngüsünü test edin

Her istemci için ilk kimlik doğrulamayı, amaçlanan uygulamayı, DNS çözümlemesini ve adres ailelerinin kapsamını test edin. Ardından yalnızca daha sonra ortaya çıkan kısımları çalışın: yenileme, uyku ve normal bir ağ değişikliği.

MOBIKE desteği ve yeniden kimlik doğrulama davranışı, az önce ölçtüğünüz kararlı sonuçtan farklı olabilir. Yalnızca arabirimin sonunda bağlı görünüp görünmediğini değil, o andaki olayı ve ilişkilendirme durumunu kaydedin.

VPN kullanılamadığında doğrudan trafiğin ne yapabileceğini tanımlayın. Bu, istemcinin yeniden bağlanıp bağlanmayacağından ayrı bir politika kararıdır ve çoğu dağıtım birinci soruyu yok sayıp ikincisini yanıtlar. Yanıtı profil adlarının yanındaki dağıtım notlarına yazın. Birinin kesinti sırasında buna ihtiyacı olacak ve yeniden oluşturmaya zamanı olmayacak.

Bir platform aynı fikirde olmadığında sunucu kimliği denetimlerini kullanın

Bir profil bir platformda çalışıp diğeri adını reddettiğinde, istemcinin gerçekte gönderdiği tanımlayıcıyı sertifikanın taşıdığı tanımlayıcılarla karşılaştırın. Bu karşılaştırma bu durumların çoğunu şifre listelerini değiştirmekten daha hızlı çözer.

Test edilen matrisi yapılandırma kaynağı ve güncelleme prosedürüyle birlikte saklayın. Eski bir istemci için destek sona erdiğinde, bir sonraki denetimin bulması için ağ geçidinde daha zayıf uyumluluk ayarlarını gizli bırakmak yerine istisnasını bilerek kaldırın. strongSwan'ın IKEv2 belgeleri değişimlerin nasıl yapılandırıldığına dair yararlı bir kaynaktır.

İlgili makaleler