VPN რელე SSH-ის მიღებას წყვეტს: ფაილის დესკრიპტორების ლიმიტები

WireGuard-ის ხელის ჩამორთმევა ჯერ კიდევ სრულდება, peer ჯერ კიდევ ახალ endpoint-ს აჩვენებს, და მაინც მის უკან მდგომი რელეს გავლით ახალი SSH სესია ბანერის გარეშე იკიდება. ეს კომბინაცია გვირაბიდან შორს, იმ პროცესისკენ მიუთითებს, რომელიც socket-ს იღებს. socat-ის მსგავსი რელე აპლიკაციის გზაზე ზის თავისი დესკრიპტორების ბიუჯეტით, თავისი შვილებით და თავისი მემკვიდრეობითი ლიმიტებით. ქვემოთ მოცემული სვლა კლიენტიდან იწყება და პირველ კომპონენტზე ჩერდება, რომელსაც კიდევ ერთი socket-ის გახსნა არ შეუძლია.

მიჰყევით გზას, სანამ რიცხვს შეცვლით

მიჰყევით ერთ წარუმატებელ მოთხოვნას, ნაცვლად იმისა, რომ მთელ გვირაბზე მსჯელობდეთ. კლიენტი გვირაბში წერს, VPN-დემონი შიფრს ხსნის და მარშრუტიზაციას აკეთებს, ხოლო რელე მეორე მხარეს იღებს. ყოველი ნაბიჯი დესკრიპტორებს ხარჯავს, და ის, რომელიც ჩვეულებრივ იწურება, ბოლოა.

დაიწყეთ მოთხოვნით, რომლის გამეორებაც შეგიძლიათ და გაზომეთ მისი დრო. თუ TCP ხელის ჩამორთმევა სრულდება, მაგრამ აპლიკაციის ბანერი არ მოდის, რელემ socket აიღო და შემდეგ შვილში ან თავის ზედა ფეხზე გაიჭედა. თუ თავად ხელის ჩამორთმევა არასდროს სრულდება, მიზეზი მარშრუტიზაცია, firewall ან მსმენელის მდგომარეობაა და არა დესკრიპტორების ზღვარი. ჩაწერეთ, რომელი ორი ფორმიდან დააკვირდით, რადგან ისინი სხვადასხვა პროცესზე მიუთითებს.

დათვალეთ სამუშაოს გამომრევი ნახტომებიც. განშტოებული მსმენელი ყოველ მიღებულ socket-ს გადასცემს შვილს, რომელიც საკუთარ ასლს ინახავს, ამიტომ რეალური ჯამი მთელი ხის თვისებაა და არა მხოლოდ მშობლის.

წაიკითხეთ ლიმიტი, რომელიც რელემ მემკვიდრეობით მიიღო

ერთადერთი მნიშვნელოვანი ლიმიტი მოქმედ პროცესს ეკუთვნის და ის დააწესა იმან, რაც ეს პროცესი გაუშვა. ulimit -n-ის აკრეფა shell-ში shell-ს აღწერს. ჰკითხეთ სერვისის მენეჯერს, რა გამოიყენა, შემდეგ დაადასტურეთ PID-ზე.

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

limits ფაილი ბეჭდავს რბილ და მაგარ ზღვრებს ისე, როგორც პროცესი ხედავს მათ. დაბალი რბილი მნიშვნელობა უხვი მაგარი მნიშვნელობის ქვეშ ნიშნავს, რომ დემონს უფლება აქვს საკუთარი ზღვარი აიწიოს, და ზოგი ამას გაშვებისას აკეთებს; თანაბარი დაბალი მნიშვნელობები ნიშნავს, რომ წყარო unit ფაილია.

Drop-in-ები ლექსიკოგრაფიული რიგით იტვირთება და გვიანდელი ფაილები იმარჯვებენ, ამიტომ systemctl cat vpn-relay.service არის ავტორიტეტული ხედი იმისა, რაც მოქმედებს. იმ ფაილის რედაქტირება, რომელსაც მენეჯერი არასდროს კითხულობს, ყველაზე გავრცელებული მიზეზია, რომ გაზრდილ რიცხვს ეფექტი არ აქვს.

გამოყავით სტაბილური პარალელურობა შენახული მდგომარეობიდან

ორი პროცესი შეიძლება ერთსა და იმავე ზღვარს მივიდეს ურთიერთდაუკავშირებელი მიზეზებით, და საშუალებები განსხვავდება. სასარგებლო პარალელურ სესიებს რომ მიჰყვება მოთხოვნა, ეს შესაძლებლობის საკითხია. ზრდა, რომელიც სამუშაოს დასრულების შემდეგ გრძელდება, გაჟონვაა ან სესიების ნაკრები, რომელიც არავის დაუხურავს.

გაზომეთ უმოქმედოდ, თქვენს ჩვეულ პიკზე და კიდევ რამდენიმე წუთის შემდეგ, რაც დატვირთვა შეწყდება. ღია ჩანაწერების ls /proc/PID/fd | wc -l-ით დათვლა რბილი ლიმიტის წინააღმდეგ გითხრობთ სხვაობას, და ზღვარზე ერთი-ორით დაბალი რაოდენობა მკაცრი გაჩერებაა და არა ნელი გზა.

როცა რაოდენობა არ იკლებს, შეხედეთ socket-ების მდგომარეობას და არა ჯამებს. CLOSE_WAIT-ში მჯდომი დესკრიპტორები ნიშნავს, რომ peer-მა დახურა, თქვენმა მხარემ კი არასდროს, და ეს აპლიკაციის სასიცოცხლო ციკლის ნაკლია, რომელსაც უფრო დიდი ლიმიტი მხოლოდ აყოვნებს. შეზღუდეთ შვილების მოდელიც: განშტოებული რელე პარალელურ შვილებზე ზღვრის გარეშე ერთად ხარჯავს დესკრიპტორებს, პროცესის სლოტებს და მეხსიერებას.

შეამოწმეთ ახალი მნიშვნელობა ცოცხალ პროცესზე

unit-ის რედაქტირების შემდეგ გადატვირთეთ მენეჯერი და გადაუშვით სერვისი, რადგან მხოლოდ გადატვირთვა არასდროს ცვლის ლიმიტებს, რომლებიც მოქმედმა პროცესმა უკვე მემკვიდრეობით მიიღო. დაადასტურეთ იმ პროცესზე, რომელიც ნამდვილად ემსახურება ტრაფიკს.

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 ხაზი ახალ წყვილს აბრუნებს; თუ ის ჯერ კიდევ ძველს აჩვენებს, თქვენ მიერ რედაქტირებული drop-in არ არის ის, რაც იტვირთება. ss რაოდენობა თქვენი დატვირთვის შემოწმებაა, ამიტომ გახსენით მოსალოდნელი სესიების რაოდენობა და უყურეთ, როგორ იზრდება. რაოდენობა, რომელიც ამ სესიების დახურვის შემდეგაც იზრდება, ნიშნავს, რომ ლიმიტი არასდროს ყოფილა მთელი პრობლემა.

ნებისმიერ დიდ ზრდას ერთი გაფრთხილება ახლავს. აპლიკაციები, რომლებიც select()-ით იკითხავენ, ვერ აკვირდებიან FD_SETSIZE-ზე მაღლა დესკრიპტორებს, რაც ტიპურ Build-ებში 1024-ია, ამიტომ ამაზე მაღლა აწეულმა ზღვარმა შეიძლება გამოიწვიოს უკავშირო შეცდომები. systemd-ის შესრულების ცნობარი იმავე გაფრთხილებას ატარებს მის მიერ გაშვებული სერვისებისთვის.

შეინარჩუნეთ გადაუშვა გვირაბის ხელმისაწვდომობისგან მოშორებით

რელეს გადაუშვა მის აქტიურ სესიებს აგდებს, და ეს VPN-ის ვარდნისგან ცალკე მოვლენაა. ისე დაალაგეთ ცვლილება, რომ გვირაბი ზემოთ დარჩეს, სანამ რელე ციკლს აკეთებს, და გააფრთხილეთ ყველა, ვისი ხანგრძლივი სესიაც მას კვეთს.

უკან დაბრუნება წინა unit ფაილია პლუს კიდევ ერთი გადაუშვა, და ეს ფაილი ადგილზე რჩება, სანამ ახალი მნიშვნელობა სამუშაო დღეს გადაიტანს. შემდეგ დახურეთ ციკლი თავდაპირველად წარუმატებელი მოთხოვნით: ერთი ახალი SSH სესია რელეს გავლით, ერთი გადაცემა, რომელიც საკმარისად გრძელია რომ მნიშვნელოვანი იყოს, და დესკრიპტორების რაოდენობა, რომელიც უმოქმედო დონეს უბრუნდება.