VPN rölesi SSH kabul etmeyi bırakıyor: dosya tanımlayıcı sınırları

Bir WireGuard el sıkışması hâlâ tamamlanıyor, eş hâlâ yakın tarihli bir uç nokta gösteriyor ve yine de arkasındaki röle üzerinden yeni bir SSH oturumu herhangi bir banner olmadan asılı kalıyor. Bu kombinasyon tünelden uzaklaşıp soketi kabul eden sürece işaret ediyor. socat gibi bir röle, kendi tanımlayıcı bütçesi, kendi çocukları ve kendi devralınan sınırlarıyla uygulama yolunda oturur. Aşağıdaki yürüyüş istemcide başlar ve bir soket daha açamayan ilk bileşende durur.

Bir sayıyı değiştirmeden önce yolu izleyin

Tünelin tamamı hakkında akıl yürütmek yerine tek bir başarısız isteği izleyin. İstemci tünele yazar, VPN arka plan programı şifreyi çözer ve yönlendirir, röle ise diğer tarafta kabul eder. Her adım tanımlayıcı tüketir ve genellikle tükenen sonuncudur.

Yeniden üretebileceğiniz bir istekle başlayın ve süresini ölçün. TCP el sıkışması tamamlanıyor ancak uygulama banneri gelmiyorsa, röle soketi almış ve sonra bir çocukta ya da yukarı yönlü bacağında takılmıştır. El sıkışmanın kendisi hiç tamamlanmıyorsa neden yönlendirme, güvenlik duvarı veya dinleyici durumudur, tanımlayıcı tavanı değil. İki biçimden hangisini gördüğünüzü not edin, çünkü farklı süreçlere işaret ederler.

İşi kopyalayan atlamaları da sayın. Dallanan bir dinleyici, kabul edilen her soketi kendi kopyasını tutan bir çocuğa verir, bu yüzden gerçek toplam yalnızca ebeveynin değil, tüm ağacın özelliğidir.

Rölenin devraldığı sınırı okuyun

Önemli olan tek sınır, çalışan sürece aittir ve onu o süreci başlatan şey belirlemiştir. Bir kabukta ulimit -n yazmak kabuğu tarif eder. Hizmet yöneticisine neyi uyguladığını sorun, ardından PID üzerinde doğrulayın.

systemctl show -p MainPID -p LimitNOFILE vpn-relay.service
cat /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits

limits dosyası yumuşak ve katı tavanları sürecin gördüğü gibi yazdırır. Cömert bir katı değerin altındaki düşük yumuşak değer, arka plan programının kendi tavanını yükseltebileceği anlamına gelir ve bazıları bunu başlangıçta yapar; eşit düşük değerler kaynağın unit dosyası olduğu anlamına gelir.

Drop-in dosyaları sözlük sırasıyla yüklenir ve sonraki dosyalar kazanır, bu yüzden systemctl cat vpn-relay.service neyin geçerli olduğunun yetkili görünümüdür. Yöneticinin hiç okumadığı bir dosyayı düzenlemek, yükseltilen bir sayının etkisiz olmasının en yaygın nedenidir.

Kararlı eşzamanlılığı tutulan durumdan ayırın

İki süreç ilgisiz nedenlerle aynı tavana çarpabilir ve çareler farklıdır. Yararlı eşzamanlı oturumları izleyen talep bir kapasite sorunudur. İş bittikten sonra devam eden büyüme bir sızıntı ya da kimsenin kapatmadığı bir oturum kümesidir.

Boşta, normal zirvenizde ve yük durduktan birkaç dakika sonra tekrar ölçün. Açık girişleri ls /proc/PID/fd | wc -l ile yumuşak sınıra karşı saymak size boşluğu söyler ve tavanın bir iki altındaki sayı yavaş bir yol değil, sert bir duruştur.

Sayı düşmeyi reddettiğinde toplamlara değil, soket durumlarına bakın. CLOSE_WAIT içinde oturan tanımlayıcılar, eşin kapattığı ve sizin tarafınızın hiç kapatmadığı anlamına gelir; bu, daha büyük bir sınırın yalnızca ertelediği bir uygulama yaşam döngüsü kusurudur. Çocuk modelini de sınırlayın: eşzamanlı çocuklara tavan koymayan dallanan bir röle tanımlayıcıları, süreç yuvalarını ve belleği birlikte tüketir.

Yeni değeri canlı süreçte doğrulayın

Unit dosyasını düzenledikten sonra yöneticiyi yeniden yükleyin ve hizmeti yeniden başlatın, çünkü tek başına yeniden yükleme, çalışan bir sürecin zaten devraldığı sınırları asla değiştirmez. Gerçekten trafik sunan süreçte doğrulayın.

systemctl daemon-reload
systemctl restart vpn-relay.service
awk '/Max open files/ {print}' /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits
ss -tnp state established '( sport = :2222 )' | wc -l

awk satırı yeni çifti döndürür; hâlâ eskisini gösteriyorsa, düzenlediğiniz drop-in yüklenen değildir. ss sayısı yük denetiminizdir, bu yüzden beklediğiniz oturum sayısını açın ve yükselişini izleyin. Bu oturumlar kapandıktan sonra artmaya devam eden bir sayı, sınırın hiçbir zaman sorunun tamamı olmadığı anlamına gelir.

Her büyük artışa bir uyarı eşlik eder. select() ile yoklayan uygulamalar FD_SETSIZE üzerindeki tanımlayıcıları izleyemez; bu, tipik derlemelerde 1024'tür, bu yüzden bunun üzerine çıkarılan bir tavan ilgisiz görünen hatalar üretebilir. systemd yürütme başvurusu başlattığı hizmetler için aynı uyarıyı taşır.

Yeniden başlatmayı tünel kullanılabilirliğinden uzak tutun

Röleyi yeniden başlatmak etkin oturumlarını düşürür ve bu VPN'in çökmesinden ayrı bir olaydır. Değişikliği, röle dönerken tünel ayakta kalacak şekilde sıralayın ve uzun ömürlü oturumu bunu kesen herkesi uyarın.

Geri alma, önceki unit dosyası artı bir yeniden başlatmadır ve o dosya, yeni değer bir iş gününü atlatana kadar yerinde kalır. Sonra döngüyü başlangıçta başarısız olan istekle kapatın: röle üzerinden yeni bir SSH oturumu, anlamlı olacak kadar uzun bir aktarım ve boşta düzeyine dönen bir tanımlayıcı sayısı.