Bir OpenVPN kanca betiği az önce kurduğu tüneli kullanabilir mi?

Bir kanca betiğinin tünelin diğer tarafına ulaşıp ulaşmayacağı üç koşula bağlıdır: hangi olaya bağlı olduğu, betik çalışırken OpenVPN'in hâlâ kendi başlatma dizisinin içinde olup olmadığı ve işin o diziden ayrılıp ayrılmadığı. Çoğu betik üçüncüsünde başarısız olur. Bir uyku eklemek, yaşam döngüsü sorununu bir zamanlama sorunu olarak ele alır ve yanıltmaya yetecek kadar sık işe yarar.

Önce olaya karar verin, sonra işi erteleme mekanizmasına, sonra ertelenen işin çalıştığı yere. Bu üç karar birbirinden bağımsızdır ve bunları karıştırmak, iki satırlık bir kancanın koca bir öğleden sonraya dönüşme biçimidir.

Kanca neden kendisini bekleyen bir tüneli bekler

OpenVPN kancalarını eşzamanlı olarak çağırır, paketleri taşıyan aynı sürecin içinde. up, tun veya tap aygıtı var olduğunda ama herhangi bir rota eklenmeden önce tetiklenir; route-up ise rotalardan sonra tetiklenir; bu anların hiçbiri karşı tarafın yanıt vereceğini vaat etmez. Herhangi bir kancanın betiği hâlâ çalışırken arka plan süreci iletmez, bu yüzden trafiğin tünelden geçmesini bekleyen komut, o komutu bekleyen bir tüneli bekler. Bu döngüsel bekleme, elle çalıştırmanın geçmesinin ve kancanın zaman aşımına uğramasının nedenidir.

Bariz yama, yani birkaç saniye uyumak, bazen işe yarar çünkü uzak uç kendi kendine ayağa kalkmıştır, uyku bir şeyi düzelttiği için değil. Hazır olup olmadığını soran bir yardımcı başka bir yanıttır: kanca döner, iletme başlar ve yardımcı ihtiyacı olanı gerçekten orada olduğunda alır.

Kancayı kolaylığa göre değil, olaya göre seçin

up'yi yalnızca aygıta ihtiyaç duyan işe, route-up'ü rotalara ihtiyaç duyan işe bağlayın ve client-connect ile client-disconnect'ü sunucu tarafındaki her istemciye özel görevler için saklayın. Bağlantı kesildiğinde temizlik iki kez çalışmayı kaldırmalıdır, çünkü kalıcı bir arayüz üzerinden yeniden bağlanmalar tam bir yeniden başlatmayla aynı diziyi izlemez. Sunucuda client-connect, arka plan süreci başladığında değil, istemci kimlik doğruladığında tetiklenir; mantığı oraya taşımadan önce bunu doğrulamaya değer. İş, tek bir bağlantıya değil hizmetin yaşam döngüsüne aitse, bir systemd birimi herhangi bir kancadan daha iyi bir evdir.

Kanca komutlarını arka plan süreci doğrudan yürütür, arada kabuk yoktur, bu yüzden up satırındaki ifconfig_remote kelimesi kelimesine metin olarak gelir. Komutu açık bir kabuğa sarın ya da mantığı ortamı okuyan bir betikte tutun. ipchange kendi argümanlarını ekleyen tek bir yönergedir: komuta adresi ve bağlantı noktasını verir, bu yüzden hiçbiri için yazılmamış bir betik iki beklenmedik argüman görür.

İşi ayırmanın üç yolu

İlk seçenek yardımcıyı kancanın içinden arka plana göndermektir: setsid veya systemd-run --scope ile başlatın, devralınan tanımlayıcıları kapatın ve hemen sıfırla çıkın. İkincisi, kancanın küçük bir durum dosyası yazmasına ve bir systemd zamanlayıcısının veya yol biriminin onun üzerinde işlem yapmasına izin vermektir; bu, kancayı önemsiz tutar ve yeniden deneme ilkesini günlüklerin bulunduğu yere koyar. Üçüncüsü, kancayı tamamen bırakıp işi VPN hizmetinden sonra sıralanan bir birime taşımaktır; bu, iş hiç de bağlantı başına değilse doğru yanıttır. Üçü de tek bir kuralı paylaşır: kanca tünele ihtiyaç duymadan önce dönmelidir.

Hangisini seçerseniz seçin, yardımcıyı idempotent ve gözlemlenebilir yapın. Üst üste binen iki çağrı aynı geri alınamaz eylemi iki kez yürütmemeli ve başarısız olan bir yardımcı insanın okuyabileceği bir şey bırakmalıdır.

Sandbox arızalarını yaşam döngüsü arızalarından ayırın

Bir betik root isteminden çalışıp hizmet olarak başarısız olduğunda neden genellikle ağ değil sandbox'tır. Kısıtlayıcı bir ProtectHome, salt okunur bir ProtectSystem veya var olmayan bir çalışma dizini betiği veya verilerini erişilemez bırakabilir ve bir SELinux ana bilgisayarında dosyanın yürütmeye izin veren bir bağlama da ihtiyacı vardır. Birimi systemctl cat openvpn-server@server ile, günlüğü journalctl -u openvpn-server@server -n 80 ile okuyun, sonra bağlantı zaman aşımı yerine izin veya bağlam hatası arayın. Sandbox'ı devre dışı bırakmak ilk değil, son hamle olmalıdır.

Yaşam döngüsü arızası farklı görünür: kanca başlar, yardımcı çalışır ve soket henüz orada değildir. Kancanın kendisinden zaman damgalı bir satır yazın, bağlantıyı kesip yeniden bağlanın ve olayları sırayla okuyun. Yardımcı gerçekten tünele ihtiyaç duyuyorsa, sabit bir süre uyumak yerine hazır olup olmadığını sormasına izin verin.

Üç alan bir sonraki raporu yararlı kılar: hangi kanca çalıştı, hangi hesabı kullandı ve nerede durdu. Bunlar olmadan sonraki her soruşturma baştan başlar.