İstemci sertifikası olmadan OpenVPN: profil değil, sunucu politikası

Sertifika ve anahtar satırlarını silersiniz, profili teslim edersiniz ve bağlantı hâlâ bir sertifika hatasıyla başarısız olur. Profil hiçbir zaman bu gereksinimi uygulayan şey olmadı. İstemci sertifikasının zorunlu olup olmadığına sunucu karar verir ve istemci tarafındaki hiçbir düzenleme bunu görüşerek kaldırmaz. Dolayısıyla düzeltme, bilinçli olarak yapılan bir sunucu politikası değişikliğidir ve ona bağlı her şey aynı geçişte güncellenir.

Profil politika değildir

Community OpenVPN 2.6 istemci sertifikaları zorunlu olarak gelir, çünkü verify-client-cert varsayılan olarak require değerindedir. Bunu none olarak ayarlamak, sertifika talebini durduran ve istemci kimlik doğrulamasını sunucunun zaten çalıştırdığı kullanıcı adı ve parola düzenine bırakan şeydir. Eski kılavuzlar aynı fikrin eski yazımı olan client-cert-not-required seçeneğine uzanır, bu yüzden kurulu sürümünüzün belgelediği yönergeyi kullanın. Her hâlükârda değişiklik sunucuda gerçekleşir ve hiçbir istemci profili bunu yapamaz.

Aşağıdaki parça sunucu tarafındaki değişikliğin tamamıdır ve tek başına çalışan bir kimlik doğrulama yapılandırması değildir. verify-client-cert none sertifika gereksinimini kaldırırken username-as-common-name hesap adını, sonraki geri çağırmaların ve istemci başına dosyaların gördüğü kimlik hâline getirir. Satırların hiçbiri bir parolayı denetlemez, bu yüzden yine de bir doğrulayıcı bulunmalıdır.

verify-client-cert none
username-as-common-name

Bu doğrulayıcı, auth-user-pass-verify tarafından yürütülen bir eklenti veya betiktir ve yukarıdaki satırlardan herhangi biri bir anlam ifade etmeden önce yerinde olmalıdır. Sırayı tersine çevirmek, sunucunun sertifika istemediği ve hiçbir hesabı denetlemediği bir pencere yaratır.

Sunucuyu hâlâ ne doğruluyor

İstemci sertifikasını bırakmak TLS'i bırakmak değildir. Sunucu kendi sertifikasını ve anahtarını korur, istemci ise onu bir sahtekârla konuşmaktan alıkoyan CA güvenini ve ana makine adı denetimlerini korur. İstemcinin artık sertifikası yok diye remote-cert-tls server veya CA paketini kaldırmak yaygın ve ciddi bir yanlış okumadır ve 2.6 başvurusu iki yönün bağımsız olduğunu açıkça belirtir. Biri sunucuyu istemciye kanıtlar; diğeri istemciyi sunucuya.

Bir profil ayrıca bir tls-auth veya tls-crypt bloğu taşıyabilir. Bu, kendi dağıtım ve döndürme döngüsü olan paylaşılan bir denetim kanalı anahtarıdır, bu yüzden sertifika veya anahtar satırı olmayan bir dosya otomatik olarak yayımlamak için güvenli değildir. Onu okuyana kadar bir sır olarak işleyin.

Çalışan bir profilden kopyalanan bir sertifika dosyası tek başına hiçbir şeyi kanıtlamaz; sahiplik, ona uyan özel anahtarı elde tutmak demektir ve sertifikayla kimlik doğrulanan bir kurulum bunu denetler. Bir sertifika içeren dosya, onunla kimlik doğrulanabilen bir dosya değildir.

Doğrulayıcı ne yapmalı

Sertifika gereksinimi kaldırıldığında her şey doğrulayıcıya dayanır: bir eklenti veya auth-user-pass-verify tarafından yürütülen bir betik. Geçersiz kimlik bilgilerini reddetmeli, devre dışı veya uygun olmayan hesapları reddetmeli ve arka ucuna ulaşamadığında kapalı şekilde başarısız olmalıdır. username-as-common-name çoğu zaman yanında etkinleştirilir ve sonraki geri çağırmaların ve istemci başına yapılandırma dosyalarının gördüğü kimliği değiştirir. Bir parolayı doğrulamaz ve uygun olmayan bir hesabı uygun hâle getirmez. Bunlar ayrı işlerdir ve onları karıştırmak, bir geçişin mutlu yol testini geçip ilk gerçek olayında başarısız olmasının yoludur.

Olumsuz durumları olumlu durum kadar dikkatle test edin. Bir parola istemi gösteren profil, yalnızca istemcinin bir istem çizebildiğini kanıtlar; yanlış parolayı kabul eden bir sunucu ise çok daha kötü bir şeyi kanıtlar. Test kümesine yalnızca kötü bir parola değil, devre dışı bir hesap ve süresi dolmuş bir kimlik bilgisi de ekleyin.

Politikayı, profili ve eşlemeyi birlikte değiştirin

Üç şeyi eşgüdümleyin: sunucu yönergesi, istemci profili ve istemci başına kimlik eşlemesi. Bunları ayrı ayrı değiştirirseniz istemciler doğrulamadan önce başarısız olur ya da yöneticinin beklemediği bir adla bağlanır; bu daha kötüdür çünkü başarı gibi görünür. Yanlış kimlik altında başarılı olan bir bağlantıyı fark etmek, başarısız olandan daha zordur.

Bu yol için iki test hesabı tutun, biri geçerli biri bilinen kötü, ve doğrulayıcıdaki her değişiklikten sonra ikisini de kullanın. Geçerli hesap mutlu yolu ve kimlik eşlemesini kanıtlar; kötü olan reddetmenin hâlâ çalıştığını kanıtlar. Testlerin hiçbiri size uygunluk kuralları hakkında bir şey söylemez, bu yüzden dağıtımda böyle kurallar varsa politik nedenlerle reddedilmesi gereken bir hesap ekleyin. Her değişiklikten sonra üçünü de çalıştırın, çünkü her şeyi kabul etmeye başlayan bir doğrulayıcı tam olarak çalışan bir oturum açma gibi görünür.

Sunucunun gerçekte hangi kimlik doğrulama yöntemlerini kabul ettiğini kaydedin, profilin önerdiği yöntemleri değil. Bu kayıt, insanların sürekli sorduğu soruyu yanıtlar: bu hizmete kimler bağlanabilir. Ayrıca bir sonraki yöneticiden daha uzun yaşar; o kişi aksi hâlde bunu bir paket yakalamasından yeniden keşfederdi.