WireGuard əl sıxışması hələ də tamamlanır, peer hələ də təzə endpoint göstərir, lakin arxasındakı reledən keçən yeni SSH sessiyası heç bir banner olmadan asılır. Bu birləşmə tuneldən uzağa, soketi qəbul edən prosesə tərəf işarə edir. socat kimi rele öz deskriptor büdcəsi, öz uşaq prosesləri və öz miras qalan limitləri ilə tətbiq yolunda oturur. Aşağıdakı gəzinti klientdən başlayır və başqa soket aça bilməyən ilk komponentdə dayanır.

Rəqəmi dəyişməzdən əvvəl yolu izləyin

Bütün tunel haqqında düşünmək əvəzinə bir uğursuz sorğunu izləyin. Klient tunelə yazır, VPN daemonu şifrəni açır və marşrutlaşdırır, rele isə qarşı tərəfdə qəbul edir. Hər addım deskriptor sərf edir və adətən tükənən sonuncudur.

Yenidən qura biləcəyiniz bir sorğu ilə başlayın və vaxtını ölçün. TCP əl sıxışması tamamlanırsa, amma tətbiq banneri gəlmirsə, rele soketi alıb sonra uşaqda və ya yuxarı ayağında ilişib. Əl sıxışması özü heç vaxt tamamlanmırsa, səbəb deskriptor tavanı deyil, marşrutlaşdırma, firewall və ya dinləyici vəziyyətidir. Gördüyünüz iki formadan hansını qeyd edin, çünki onlar müxtəlif proseslərə işarə edir.

İşi təkrarlayan atlamaları da sayın. Şaxələnən dinləyici hər qəbul edilən soketi öz nüsxəsini saxlayan uşağa verir, buna görə real cəm yalnız valideynin deyil, bütün ağacın xassəsidir.

Relenin miras aldığı limiti oxuyun

Əhəmiyyətli olan yeganə limit işləyən prosesə aiddir və onu həmin prosesi başladan hər şey təyin edib. Qabıqda ulimit -n yazmaq qabığı təsvir edir. Xidmət menecerindən nə tətbiq etdiyini soruşun, sonra PID-də təsdiqləyin.

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

limits faylı yumşaq və sərt tavanları prosesin gördüyü kimi çap edir. Səxavətli sərt dəyərin altında aşağı yumşaq dəyər daemonun öz tavanını qaldıra biləcəyi deməkdir və bəziləri bunu başlanğıcda edir; bərabər aşağı dəyərlər unit faylının mənbə olduğunu bildirir.

Drop-in faylları leksik qaydada yüklənir və sonrakı fayllar qalib gəlir, buna görə systemctl cat vpn-relay.service nəyin tətbiq olunduğunun etibarlı görünüşüdür. Menecerin heç vaxt oxumadığı faylı redaktə etmək qaldırılmış rəqəmin təsirsiz qalmasının ən çox yayılmış səbəbidir.

Sabit paralelliyi saxlanan vəziyyətdən ayırın

İki proses eyni tavanı əlaqəsiz səbəblərdən vura bilər və çarələr fərqlidir. Faydalı eyni vaxtlı sessiyaları izləyən tələb tutum məsələsidir. İş bitdikdən sonra davam edən artım sızma və ya heç kimin bağlamadığı sessiyalar toplusudur.

Boşdayanmada, normal pik nöqtənizdə və yük dayandıqdan bir neçə dəqiqə sonra ölçün. Açıq girişləri ls /proc/PID/fd | wc -l ilə yumşaq limitə qarşı saymaq sizə boşluğu deyir və tavandan bir-iki aşağı olan say yavaş yol deyil, sərt dayanmadır.

Say azalmaqdan imtina edəndə, cəmlərə deyil, soket vəziyyətlərinə baxın. CLOSE_WAIT içində oturan deskriptorlar peerin bağlandığını, sizin tərəfin isə heç vaxt bağlamadığını bildirir; bu, daha böyük limitin yalnız təxirə saldığı tətbiq həyat dövrü qüsurudur. Uşaq modelini də məhdudlaşdırın: eyni vaxtlı uşaqlara hədd qoymayan şaxələnən rele deskriptorları, proses yuvarlarını və yaddaşı birlikdə tükədir.

Yeni dəyəri canlı prosesdə yoxlayın

Unit faylını redaktə etdikdən sonra meneceri yenidən yükləyin və xidməti yenidən başladın, çünki tək yenidən yükləmə artıq işləyən prosesin miras aldığı limitləri heç vaxt əvəz etmir. Trafiki həqiqətən xidmət edən prosesdə yoxlayı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 sətri yeni cütü qaytarır; hələ də köhnəni göstərirsə, redaktə etdiyiniz drop-in yüklənən deyil. ss sayı sizin iş yükü yoxlamanızdır, buna görə gözlədiyiniz sessiya sayını açın və onun qalxdığını izləyin. Həmin sessiyalar bağlandıqdan sonra artmağa davam edən say limitin heç vaxt bütün problem olmadığını bildirir.

İstənilən böyük artımla bir xəbərdarlıq gəlir. select() ilə sorğu edən tətbiqlər FD_SETSIZE-dən yuxarı deskriptorları izləyə bilməz, tipik quruluşlarda bu 1024-dür, buna görə bundan yuxarı qaldırılmış tavan əlaqəsiz görünən uğursuzluqlar yarada bilər. systemd icra arayışı başlatdığı xidmətlər üçün eyni xəbərdarlığı daşıyır.

Yenidən başlatmanı tunel mövcudluğundan uzaq saxlayın

Relenin yenidən başladılması onun aktiv sessiyalarını atır və bu, VPN-in söndüyündən ayrı bir hadisədir. Dəyişikliyi elə sifariş edin ki, rele dövr edərkən tunel qalsın və uzun ömürlü sessiyası onu keçən hər kəsi xəbərdar edin.

Geri qaytarma əvvəlki unit faylı üstəgəl başqa bir yenidən başlatmadır və həmin fayl yeni dəyər tam bir iş günü keçənə qədər yerində qalır. Sonra dövrəni əvvəlcə uğursuz olan sorğu ilə bağlayın: reledən keçən bir yeni SSH sessiyası, əhəmiyyətli qədər uzun bir ötürmə və boş səviyyəsinə qayıdan deskriptor sayı.

Əlaqəli məqalələr