İstemci kancası mı sunucu kancası mı? Bir OpenVPN betiği nerede çalışır

Görev açık: bir dizüstü bilgisayar bağlandığında, dizüstünde bir şeyler değişmelidir. Düzenlenen yapılandırma sunucuya aittir ve varsayım tam orada kırılır. Sunucu dosyasındaki bir yol, o sunucudaki bir dosyayı adlandırır ve ne kadar push yapılırsa yapılsın, hangi sürecin onu yürüttüğü değişmez. İki kanca arasında seçim yapmak çoğunlukla işin hangi makineye ait olduğuna karar vermek ve bundan doğan sınırları kabul etmektir.

İki makine, önce yanıtlanması gereken iki soru

Durum değişikliğinin nerede olması gerektiğini sorun, ardından hangi olayın buna karşılık geldiğini sorun. Değişiklik kullanıcı başına yetkilendirme veya istemci başına yapılandırma kararıysa, kullanıcı dizininin bilindiği yere aittir: sunucuya. Değişiklik bir yolsa, bir resolver ayarı veya uç noktadaki yerel bir yardımcıysa, uç noktaya aittir ve yalnızca uç nokta bunu yapabilir.

Bu iki soruyu ters sırada yanıtlamak, insanların Windows dizüstü bilgisayara toplu iş dosyası push etmeye çalışmasıyla sonuçlanır. Sunucu kimin bağlandığını bilir; dizüstü kendi ağ yığınının nasıl göründüğünü bilir. Hiçbiri diğerinin bilgisine sahip değildir ve girişim genellikle açık bir hata yerine sessizce başarısız olur.

İkisinden önce üçüncü bir soru sormaya değer: platform istediğiniz kancayı hiç sunuyor mu? Yapılandırmasını kendi üreten bir cihaz aynı olay adlarını sunmayabilir ve .ovpn dosyasını içe aktaran bir masaüstü istemcisi, dosyanın yazıldığı istemcinin aynısı olmayabilir. Platformu önce doğrulamak, orada olmayan bir kanca etrafında tasarım yapmaktan kurtarır. Ayrıca önünüzdeki makineye hangi belgelerin gerçekten uygulandığını söyler.

Sunucu tarafı seçeneği: bağlantı başına bir olay

Bir client-connect betiği, kimliği doğrulanmış bir istemci bağlandığında sunucunun süreç bağlamında çalışır ve common name ile atanan adres gibi belgelenmiş bağlantı ayrıntılarını alır. İstemci başına yapılandırma parçası yazmak, bir politika kararını uygulamak veya sunucunun sahip olduğu durumu kaydetmek için doğru yerdir.

İnsanların kaçırdığı ayrım, o kanca ile sunucunun up kancası arasındaki farktır. up kancası, sunucu tünel aygıtını açtığında tetiklenir; çok istemcili bir sunucuda bu, daemon başlangıcında bir kez olur. Bu, oturum açma başına bir olay değildir ve oraya konulan kod, kullanıcılar bağlandığında değil hizmet başladığında çalışır.

Web arayüzü olan bir cihazda, üretilen daemon dosyalarını düzenlemek yerine desteklenen uzantı mekanizmasını kullanın. Üretilen dosyalar bir sonraki kaydetmede yeniden yazılır ve bu yeniden yazma, değişikliğinizi en kötü anda sessizce siler. Uzantı metninin bir kopyasını cihazın dışında tutun, böylece bir aygıt yazılımı güncellemesi amacı da kaybetmez.

İstemci tarafı seçeneği: yerel olarak çalışması gereken iş

Bir topluluk istemcisi, tünel aygıtı ayağa kalktığında ve yeniden yollar kurulduğunda yerel bir betik çalıştırabilir. Bunlar iki farklı andır ve yanlış olanı seçmek, yardımcının bağlı olduğu yol henüz yokken başladığı klasik yarışı doğurur.

Yardımcı o istemcide bulunmalı, istemciyi çalıştıran hesap tarafından okunabilir ve yürütülebilir olmalı ve açık bir script-security ayarıyla izin verilmelidir. İstemciyi yönetici olarak başlattığınızda çalışan bir betik, oturum açmadan önceki bir hizmet veya başka bir kullanıcının oturumu hakkında size hiçbir şey söylemez.

Adlandırma da önemlidir. up kancası aygıt oluşturmaya, route-up ise yolların kurulmasına karşılık gelir, ancak özel bir ağın erişilebilir olmasını gerektiren bir görev, aygıt oluşturmanın her yolun, resolver girdisinin ve uygulamanın hazır olduğu anlamına geldiğini varsaymak yerine erişilebilirliği doğrulamalıdır.

Çalıştırılabilir kod push etmenin seçenekler arasında olmamasının nedeni

Push ile gönderilen seçenekler kasıtlı olarak kısıtlanmıştır ve betik çalıştıran seçenekler, sunucunun iletmesine izin verilmeyen kategoriler arasındadır. Bu kısıtlama vardır çünkü alternatif, ele geçirilmiş veya yanlış yapılandırılmış bir sunucunun her bağlanan istemcide rastgele komutlar çalıştırmasına izin verirdi.

Betik yürütmeyi yerel olarak etkinleştirmek bunu değiştirmez. script-security ayarınız kendi seçtiğiniz yerel betiklere izin verir; sunucuya yenilerini sağlama yetkisi vermez.

Amaç yalnızca VPN yollarını kurmaksa, uzaktan yürütme şeması icat etmek yerine desteklenen yol yapılandırmasını kullanın. Amaç gerçekten yerel kod gerektiriyorsa, kuruluşun uç nokta yönetimi araçlarıyla dağıtın ve kullanıcının ayrıcalıklarıyla çalışan diğer herhangi bir yazılım gibi inceleyin.

İki kancadan birine güvenmeden önce neyi doğrulamalı

Her kanca için dört şey yazın: makine, olay adı, hangi hesap altında çalıştığı ve üretmesi gereken durum değişikliği. Ardından bağlantıyı, yeniden bağlanmayı ve temizlik yolunu test edin, çünkü yeniden bağlanmada durum sızdıran bir kanca, hiç çalışmamış olandan daha kötüdür.

Gerçekten onu yürütecek hesap altında, gerçekten yürütüleceği anda test edin. openvpn(8) kılavuzu her iki kanca ailesini ve push kısıtlamalarını belgeler; dağıtım yaptığınız platform bunları hiç sunup sunmadığını belgeler. Etkileşimli bir yönetici terminalinde başarılı olan bir betik bir hipotezdir, doğrulama değil.