OpenVPN up betiği çok mu erken çalıştı, yoksa hiç mi hazır değildi?

up betiği çalışır, sıfırla çıkar ve içindeki görev, terminalden iki saniye sonra kusursuz çalışan özel bir hizmete ulaşamaz. İçgüdü zamanlamayı işaret eder ve olağan onarım bir uykudur; bu, yarışı anlamadan gizler. Daha faydalı okuma, “up”ın bir kancayı adlandırdığı, hazır olma garantisi olmadığıdır. Tünel cihazı yapılandırıldığında tetiklenir; bu, rotalardan, DNS'ten ve kesinlikle tünelin arkasındaki herhangi bir uygulamadan öncedir.

Kabuk testi başarılı oldu çünkü her şey oturduktan sonra çalıştı. Kanca tek bir belirli anda çalıştı.

up başlangıç sırasında nerede durur

OpenVPN tünel cihazını yapılandırır ve ardından up kancasını çalıştırır. Rota kurulumu daha sonraki bir aşamadır ve kendi kancası vardır, bu yüzden up içine yerleştirilen rotaya bağlı bir görev, kullanışlı yolu olmayan bir cihaz görebilir. Rota işini route-up içine koyun, zamanlama sorunu genellikle kaybolur.

Kılavuz bu sıralamayı ve her kancanın aldığı ortamı belgeler. Bu sıralama, klasik “benim kabuğumdan çalışıyor” raporunun tüm açıklamasıdır ve aynı betiğin bir makinede geçip daha yavaş rota aşaması olan başka bir makinede başarısız olmasının nedeni de budur. Sonuçların hiçbiri betiğin kalitesi hakkında bir şey söylemez.

DNS ve uygulama hazırlığı daha da sonra gelir. Kurulu rotalar bile uzak uç noktanın dinlediğinin, bir adın çözüldüğünün veya kullanıcı kapsamındaki bir görev için bir masaüstü oturumunun var olduğunun kanıtı değildir.

Kanca gerçekte neyi devralır

Bir kanca OpenVPN sürecinin hesabı ve ortamı altında çalışır, bu sizin etkileşimli kabuğunuzla aynı şey değildir. Kullanıcının oturum veri yoluna, bir masaüstü ortamına veya yalnızca girişte açılan bir kimlik bilgisine sahip olmayabilir. Görevin bunlardan hangisine gerçekten ihtiyaç duyduğunu yazın.

Bu, ağ gibi görünen ama kullanıcı bağlamına bağlı görevler için önemlidir: bir paylaşımı kullanıcı kimlik bilgisiyle bağlamak, kullanıcı başına proxy ayarlamak veya bir yazıcı yapılandırmak. Ayrıcalıklı bir tünel kancası onlar için yanlış yerdir ve ne kadar beklenirse beklensin eksik bir oturumu düzeltmez.

Bir görev bir kancada başarısız olduğunda hesabı, ortamı ve başarısız olan ilk işlemi kaydedin. Bu, erken zamanlamayı bir izin veya bağlam sorunundan ayırır ve ikisinin onarımları tamamen farklıdır. İkisi arasında tahmin yürütmek, beş dakikalık bir onarımın bütün bir öğleden sonraya dönüşme biçimidir.

Uyku eklemek neden hazır olma denetimi değildir

Bir uyku betiği geciktirir ve yarış penceresini kaydırır. Hızlı bir günde görev başarılı olur; yavaş bir günde yine başarısız olur ve gecikme işe yarıyor gibi göründüğü için arızayı yeniden üretmek zorlaşır. Yalnızca hafif yük altında çalışan bir gecikme tesadüftür, onarım değildir.

Bağımlılık bir rota ise rota kurulumuna karşılık gelen kancayı kullanın. Bağımlılık tünelin arkasındaki bir hizmetse, o belirli koşulu bekleyen ve hiç gelmediğinde açıkça başarısız olan sınırlı bir denetim kullanın.

Arızayı açık tutun. Gerçek işi başarısız olduğu halde sıfırla çıkan bir kanca, başarısız olan bir kancadan daha kötüdür, çünkü hizmet yöneticisi bir başarı kaydeder ve kimse bir daha bakmaz. Betiğin kendisinden gelen bir günlük satırı, bunu dürüst tutmanın en ucuz yoludur.

Temizlik ve yeniden bağlanma aynı özeni hak eder

Paylaşılan durumu değiştiren bir betiğin eşleşen bir geri alma yolu olmalıdır. Bir kancanın eklediği rotalar, çözümleyici girdileri ve güvenlik duvarı işaretleri idempotent ve geri alınabilir olmalıdır, aksi halde yeniden bağlanma ikinci bir kopyayı birincinin üzerine yığar.

Yeniden bağlanmalar kancaları tam bir hizmet başlangıcından daha sık çalıştırabilir. Bir oturumu yeniden kuran kalıcı bir arayüz up ve route-up döngüsünü yeniden tetikleyebilir, bu yüzden önyükleme başına tek yürütme varsayan bir betik sonunda yanlış davranacaktır. Bir günlük dalgalanma boyunca günlükteki yürütmeleri sayarak gerçekte ne sıklıkla çalıştığını görün. Ardından betiği bu kadar kez çalıştırmak için güvenli hale getirin.

Başarısız olan yaşam döngüsünü test edin, daha sonraki bir komutu değil. Önyüklemeyi veya yeniden bağlanmayı yeniden üretin, kancanın çalışmasını izleyin ve görevin gerçekten çalıştığı anda başarılı olduğunu doğrulayın. Sonradan etkileşimli bir kabuktan gelen başarı, bağımlılık hakkında kanıttır; başlangıç yolunun çalıştığının kanıtı değildir.

Her görevin bağlı olduğu olaya bir ad verin, sonra görevi o olaya bağlayın. Geri kalan her şey, denetim gibi görünen bir gecikmedir.