OpenVPN client-connect hatası: disconnect sırasında temizlik garanti mi?
Reddedilen bir istemci güvenlik duvarı kuralını veya yazılmış bir kaydı geri almaz. Callback sözleşmesini hook’unuzun kendi başına yapması gereken geri alma ile karşılaştırın.
client-connect betiği sıfır olmayan bir kodla çıktığında OpenVPN istemciyi reddeder ve operatörler genellikle eşleşen client-disconnect betiğinin ortalığı toplayacağını varsayar. Çoğu zaman hiç çalışmaz, çünkü disconnect işlemesi connect aşamasının neyi tamamlayabildiğine bağlıdır. Reddetmeyi ve geri almayı tek bir mekanizma olarak görmek, başarısız bir oturum açmayı sızmış bir güvenlik duvarı kuralına veya sahipsiz bir kayda dönüştüren şeydir. Bunlar iki ayrı yükümlülüktür ve yalnızca biri otomatiktir. Sunucuyu durum bırakmakla suçlamadan önce hook’un kendi çıkış yolunu okuyun.
Sıfır olmayan çıkış istemciyi reddeder; işinizi geri almaz
client-connect’in çıkış durumu bir kabul kararıdır. Sıfır kabul et anlamına gelir, başka her şey örneği tam olarak kurulmadan önce yıkmak anlamına gelir. Bu sözleşmede hiçbir şey betiğin dış dünyaya şimdiden ne yaptığını denetlemez. Betik bir iptables kuralı eklediyse, bir satır yazdıysa veya bir sayacı artırdıysa, bu değişiklikler reddetmeden sonra da kalır.
Aynı asimetri, tek bir örnek için birden çok connect işlevinin çalışabildiği eklentiler için de geçerlidir. Sonraki bir hata önceki bir başarıyı geriye dönük olarak iptal etmez ve önceki işlevin kardeş işlevin başarısız olduğunu öğrenmesinin bir yolu yoktur.
Reddetme otomatiktir, temizlik değildir
OpenVPN 2.6 kılavuzu, client-disconnect işlemesini önceki connect işlemesinin başarılı olmasına bağlar. Belgelenmiş bir istisna kademeli zincirleri kapsar: bir connect adımı zaten başarı döndürdüyse, sonraki connect adımı başarısız olsa bile örnek yıkılırken ilgili disconnect adımları yine de çalışır. Bu istisna dardır ve kaç callback yapılandırıldığına bağlıdır, bu yüzden tek bir shell betiğini test etmek size bir zincir hakkında hiçbir şey söylemez.
Tasarım yapmadan önce gerçek yapılandırmayı haritalayın: hangi betik, hangi eklenti ve hangi sırayla çalışıyor. Aşağıdaki tablo yarım kalmış bir kurulumun geride ne bıraktığını listeler.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
Her satır istemci için aynı, ana bilgisayar için farklı şekilde biter. İstemci hangisinin olduğunu söyleyemez, bu yüzden hook hata durumunu döndürmeden önce yaptığını geri almalıdır.
Başarısız olan betiğin içinde telafi edin
Paylaşılan duruma dokunmadan önce yapabildiğiniz her şeyi doğrulayın: sertifika alanları, adresin kullanılabilirliği, istemcinin ait olduğu grup. En ucuz reddetme, herhangi bir tahsisattan önce gerçekleşendir. Kurulum birkaç dış işlemi kapsadığında, hangilerinin tamamlandığını kaydedin ve hata durumunu döndürmeden önce bunları ters sırayla geri alın.
Somut bir durum: betik istemci başına bir güvenlik duvarı girdisi oluşturur, ardından onu tanımlayan durum satırını yazmakta başarısız olur. Başarısız dal, az önce oluşturduğu girdiyi kaldırmalı ve ardından sıfır olmayan bir kodla çıkmalıdır. Hiç zamanlanmayabilecek bir disconnect olayını beklemek, bir kuralın amaçlandığı oturumdan daha uzun yaşamasının yoludur.
Telafiyi idempotent ve sahipli yapın
Temizlik iki kez çalıştırılabilir olmalı ve neyi silebileceği konusunda kesin olmalıdır. Önceki bir denemeden gelen geç bir olay, yalnızca ikisi ortak bir adı veya geri dönüştürülmüş bir tünel adresini paylaştığı için daha yeni bir oturumun tahsisatını kaldırmamalıdır. Belirli tutamacı veya işlem kimliğini kaynakla birlikte kaydedin ve addan değil o anahtardan silin. Veritabanı işlemleri yalnızca veritabanının kendi değişikliklerine yardımcı olur; bu sınırın dışındaki bir güvenlik duvarı kuralı açık bir telafi adımı gerektirir.
Sürecin değişiklik ile temizlik arasında ölebileceğini varsayın ve dış durumu kabul edilen istemci listesiyle bir programa göre karşılaştıran bir uzlaştırıcı ekleyin.
Gerçekten farklı olan üç yolu test edin
Üç durumu çalışın: herhangi bir tahsisat yapılmadan önce reddetme, kısmi tahsisattan sonra reddetme ve daha sonra sona eren normal kabul edilmiş bir oturum. Bu üçü farklı günlük satırları ve farklı kalıntılar üretir. Her birinden sonra dış durumu doğrulayın, yalnızca istemcinin hata iletisini değil, çünkü istemcinin başarısız olması üç durumdan ikisinde beklenen sonuçtur.
Hook aşamasını, çıkış durumunu ve neyin tahsis edildiğini veya serbest bırakıldığını kimlik bilgileri olmadan günlüğe kaydedin. Oluşturduğu kaynağı adlandıran bir hook günlüğü, sızmış bir kuralı altı ay sonra bulunabilir kılan şeydir.