FreeBind'e karşı After=: bir systemd soketini VPN adresine bağlamak

Açılışta sabit bir VPN adresine bağlanan soket birimi, tünel adresi atamadan önce başarısız olabilir ve arkasındaki hizmet hiç başlamaz. İki anahtar düzeltme gibi görünür ve sorunun farklı yarılarını çözer. FreeBind, adres hâlâ yokken systemd'nin dinleyiciyi oluşturmasına izin verir. After= yalnızca işleri sıralar, bu yüzden bir şeylerin ne zaman başladığını değiştirir ama adresin daha erken gelmesini sağlamaz.

İki farklı sorun, iki farklı anahtar

İlk sorun bir bağlama hatasıdır: çekirdek, ana makinenin sahip olmadığı bir adreste dinlemeyi reddeder, bu yüzden soket birimi hemen başarısız olur ve hizmet hiçbir zaman etkinleştirilmez. İkinci sorun bir hazır bulunuşluk hatasıdır: adres eninde sonunda vardır, ancak bir şey tünel trafik taşımadan önce onu kullanmaya çalışır. FreeBind birinciyi ele alır ve ikinci için hiçbir şey yapmaz. Sıra yönergeleri ikisini de doğrudan ele almaz, çünkü yalnızca neyin hangi sırayla başlayacağına karar verirler. Gerçekten sahip olduğunuz hatayı adlandırmak bütün karardır.

Hangisine sahip olduğunuzu hizmet açıklamasından değil, günlükten doğrulayın. Bağlama hatası bir adres belirtir ve atanamadığını bildirir. Hazır bulunuşluk hatası genellikle daha sonra ortaya çıkar; karşı taraftan görülen bir zaman aşımı veya reddedilen bağlantı olarak, günlüklerde tamamen sağlıklı bir soket birimi varken.

FreeBind: dinleyici adresten önce vardır

FreeBind çekirdeğe yerel olmayan bir adrese bağlanmaya izin vermesini söyler, böylece systemd açılışta dinleyen soketi oluşturabilir ve uygulama her başladığında onu uygulamaya verebilir. Soket etkinleştirmesinin anlamı budur ve soketin arkasındaki hizmetten daha uzun yaşamasının nedeni de budur.

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

Boş atama, yeni giriş eklenmeden önce satıcı biriminden devralınan dinleme girişlerini siler; bu da her arayüzde yanıt veren artık bir wildcard dinleyicisini önler. Adresi ve bağlantı noktasını kendinizinkiyle değiştirin ve yalnızca drop-in dosyasını değil, etkin birimi doğrulayın. Paket dosyasını yerinde düzenlemek yerine birim adı altında drop-in kullanın, çünkü sonraki paket güncellemesi düzenlemeyi üzerine yazacak ve niyetten hiçbir iz bırakmayacaktır. Ardından soket biriminin beklediği yeniden yükleme ve yeniden başlatma prosedürüyle uygulayın.

systemd soket başvurusu bu seçeneğin arkasındaki IPv4 ve IPv6 davranışını belgeler ve önemli ayrıntı, bunun yönlendirmeye değil bağlamaya uygulanmasıdır. İçinde hiçbir şey adres atamaz veya VPN başlatmaz. FreeBind dinleyiciye verilen bir izindir, arayüzün yerine geçmez.

After= ve Wants=: sıra hazır bulunuşluk değildir

Sıra ve gereksinim ayrı eksenlerdir ve bunları karıştırmak doğru sırada başlayıp yine de başarısız olan birimler üretir. After=vpn-client.service yalnızca, iki iş de başlatılırsa bunun diğerinin başlatılmasını beklediği anlamına gelir. VPN'i içeri çekmez ve VPN'in bağlanmayı bitirmesini beklemez.

Wants= ve Requires= gibi gereksinim yönergeleri etkinleştirmeyi yönetir ve bağımlılık başarısız olduğunda ne olacağı konusunda farklıdır: biri devam eder, diğeri durur. Hiçbiri bağlı bir tünelin ne anlama geldiğini bilmez. Bir VPN süreci atanmış adres olmadan da, adres atanmış ama eşe giden yol olmadan da etkin olabilir ve her iki durum da bağımlılığı karşılar. Uygulama adresin var olmasını gerektiriyorsa, süreç başlangıcını hazır bulunuşluk kanıtı saymak yerine bu koşulu açıkça modelleyin.

Birimin gerçekte ne bildirdiğini systemctl cat ve systemctl show -p After -p Wants -p Requires ile kontrol edin. Üç farklı dizindeki drop-in'ler hiç yazmadığınız yönergeler ekleyebilir ve systemd yalnızca etkin birimi okur.

network-online.target'ın yapmadığı şey

network-online.target sonrasına sıralanmış bir birim, ağ yöneticisinin ağı kullanılabilir ilan etmesini bekler; bu açılışta bir eşitleme noktasıdır, sürekli bir koşul değildir. Belirli bir tünelin açık olup olmadığı hakkında hiçbir şey söylemez ve bir VPN öğleden sonra yeniden bağlandığında tekrar tetiklenmez. Onu yeniden bağlanma izleyicisi saymak, o hedefin en yaygın yanlış okunmasıdır.

systemd projesi bu ayrımı doğrudan belgeler ve pratik sonuç, tünel adresine ihtiyaç duyan her şeyin bağımlılığa kendisinin sahip olması gerektiğidir. network-online'ı bekleyip sonra tünel adresine bağlanan bir birim yalnızca tünel tesadüfen önce kalktığında doğrudur ve bu bir tasarım değil tesadüftür.

Gerçekten seçtiğiniz yaşam döngüsünü test edin

Temiz bir açılışı, adres göründükten sonraki bir isteği ve VPN düşüp geri geldikten sonraki davranışı test edin. Bu üç durum, çalışan bir dinleyiciyi çalışan bir hizmetten ayırır.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

İlk komut yeniden başlatmadan önce birim dosyası hatalarını yakalar, ikincisi birleştirilmiş birimi gösterir, üçüncüsü dinleyicinin olup olmadığını ve hangi adreste olduğunu kanıtlar. Tünel adresi beklediğiniz yerde wildcard adresinde bir dinleyici olması, boş ListenStream'in kaldırması gereken artığın tam kendisidir. Adresin kayıp kaymadığını görmek için VPN yeniden bağlandıktan sonra üçüncü komutu yineleyin.

Yaşam döngüsünü bilerek seçin: ya istikrarlı bir adresin dönmesini bekleyen serbest bağlanmış bir dinleyici ya da tünelle birlikte duran ve kurtarmada yeniden başlayan bir hizmet. Bunlar farklı tasarımlardır ve farklı şekillerde başarısız olurlar. Ardından erişim politikasını amaçladığınız kaynaklara ve yollara bağlı tutun, çünkü hedef adrese bağlanmak, kabul edilen paketlerin güvenilir bir arayüzden geldiğini gerektirmez.