OpenVPN auth-user-pass-verify betiği: çıkış kodunu doğru verin

OpenVPN giriş betiğinin tam olarak tek bir çıktısına göre hareket eder: çıkış durumuna. Betiğin yaptığı diğer her şey süslemedir. Bir kanca doğru doğrulayıcıya ulaşabilir, yanıtı ayrıştırabilir ve dostça bir satır yazdırabilir, ama yazarın amaçladığının tam tersini ifade eden bir durum döndürebilir. Önce sözleşmeyi okuyun ve bağdaştırıcıyı onun etrafına yazın; o hata sınıfının tamamı ortadan kalkar.

Sözleşme küçüktür: gönderilen hesabı tanımlayın, onaylanmış doğrulayıcıya amaçlanan soruyu sorun ve yalnızca o doğrulayıcının o istek için belgelenmiş olumlu sonucunu kabul edin. Geri kalan her şey altyapıdır.

Kancanın döndürebileceği üç durum

auth-user-pass-verify için OpenVPN 2.6 kılavuzu çıkış kodu 0'ı kabul, 1'i ret ve 2'yi ertelenmiş kimlik doğrulama olarak tanımlar. Sunucunun anladığı tek üç yanıt bunlardır ve her birinin bağlantı üzerinde farklı sonucu vardır. Son komutunun durumuyla çıkan bir betik, aslında bir günlük çağrısının ya da temizlik adımının oy vermesine izin vermiştir. Durumu her dalda açıkça yazın, doğrulayıcıya hiç ulaşmayan dallar dahil.

HTTP başarısı ile kimlik doğrulama başarısı ayrı katmanlardır ve bunları karıştırmak bu kancanın yanlış gitmesinin en yaygın yoludur. 202 yanıtı isteğin işlenmek üzere kabul edildiği anlamına gelir, parolanın doğrulandığı değil. Beklenen durumu, yanıtın biçimini ve nihai hükmü size verilen API sözleşmesinden tanımlayın ve akla yatkın görünüyor diye alan adı uydurmayın.

Yanıt gerçekten sonradan geliyorsa bu ertelenmiş yoldur ve öyle inşa edilmelidir. Hiç tamamlanmayan ertelenmiş bir deneme, zaman aşımı dolana kadar kaynakları tutar.

Kimlik bilgisi dosyasını tam yazıldığı gibi okuyun

Belgelenmiş dosya üzerinden yöntemde sunucu, kullanıcı adını ve parolayı geçici bir dosyanın ilk iki satırı olarak yazar, bu yolu betiğe verir ve betik döndüğünde dosyayı siler. O iki satırı veri olarak okuyun: dosyayı asla source etmeyin, asla değerlendirmeyin ve içeriğini süreç tablosunun görebileceği bir komut satırına asla yapıştırmayın. Parolayı bayt bayt koruyun, çünkü kullanıcı adına uygulayacağınız gibi normalleştirmek kimlik bilgisini sessizce değiştirir. O geçici dosya için kullanılan dizin bir dağıtım kararıdır, bu yüzden var olduğunu ve ana makinedeki herkes tarafından okunamadığını doğrulayın.

Doğrulayıcının kendi kimlik bilgisini kullanıcınınkinden ayrı tutun: ağ geçidi entegrasyonuna aittir, platformun sır deposunda yaşar ve yalnızca doğrulama iznine ihtiyaç duyar, bu yüzden belirli bir kişinin kimliğinin doğrulandığının kanıtı değildir. Kancanın ikinci bir parola doğrulayıcısı olmasına da izin vermeyin. Karma karşılaştırmasını elle yeniden yazmak, döngüyü en iyileştirerek güvenli hale gelmez ve bakımı yapılan bir doğrulayıcı, hesap deposunun tuzlu ve maliyetli şemasını zaten anlar.

Sınıflandırılamayan yanıtın ne anlama geldiğine karar verin

Zaman aşımları, taşıma hataları, bozuk yanıtlar ve kullanılamayan arka uç tek bir özelliği paylaşır: hiçbiri olumlu doğrulama değildir. Kanca her biri için kapalı biçimde başarısız olmalı ve operatörün üzerine gidebileceği bir neden kaydetmelidir. O neden korumalı bir günlüğe aittir, bağlanmaya çalışan kişiye döndürülen bir iletiye değil.

Doğrulayıcıya hiç ulaşmayan yollarda da aynı derecede dikkatli olun. Eksik bir yapılandırma değeri, okunamayan bir sır veya kurulmamış bir bağımlılık, kazara kabul yerine belirgin bir operasyonel işaretle ret üretmelidir. O dalları laboratuvarda bağımlılığı kaldırarak test edin, onlar hakkında akıl yürütmek yerine. Günlükleme hatasının çıkış durumunu değiştirebildiği yerde günlükleme kararın parçası olmuştur ve zararsız hale getirilmelidir.

Sunucu yapılandırması burada da önemlidir: kullanıcı tanımlı betikler yalnızca çalışan yapılandırma onları gereken güvenlik düzeyinde izin verdiğinde dikkate alınır ve bu ayar yükseltilecek bir varsayılan değil, bilinçli bir seçimdir.

Hükmü doğrulayın, yazdırılan satırı değil

Çıkış durumunu doğrudan inceleyen bir test kurun. Örnek bir kimlik bilgisi dosyası yazın, kancayı bilinen iyi ve bilinen kötü bir hesapla ona karşı çalıştırın ve betiğin yazdırdığı metni değil, kabuğun bildirdiği durumu okuyun. Bu tek denetim, bir istemci bağlanmadan önce sözleşme hatalarının çoğunu yakalar.

Ardından aynı durumları gerçek bir istemciyle üretim dışı bir dinleyiciye karşı çalıştırın ve sunucunun ne kaydettiğini doğrulayın: kabul edildi, reddedildi veya ertelendi. Devre dışı bırakılmış bir hesabı, yanlış parolayı, bozuk doğrulayıcı yanıtını, zaman aşımını ve ulaşılamayan doğrulayıcıyı kapsayın. Herhangi bir durum adlandıramadığınız bir hâle düşerse bağdaştırıcı bitmemiştir.

Tutun doğrulayıcı sonucundan çıkış durumuna eşlemeyi depoda betiğin yanında, böylece sonraki mühendis kodu tersine mühendislik yapmadan sözleşmeyi okuyabilir.