VPN релеят спира да приема SSH: лимити на файлови дескриптори

Ръкостискането на WireGuard все още завършва, партньорът все още показва скорошна крайна точка, а нова SSH сесия през релея зад него виси без банер. Тази комбинация сочи не към тунела, а към процеса, който приема сокета. Релей като socat стои в пътя на приложението със свой бюджет за дескриптори, свои деца и свои наследени лимити. Разходката по-долу започва при клиента и спира при първия компонент, който не може да отвори още един сокет.

Проследете пътя, преди да промените число

Проследете една неуспешна заявка, вместо да разсъждавате за тунела като цяло. Клиентът пише в тунела, VPN демонът дешифрира и маршрутизира, а релеят приема от другата страна. Всяка стъпка изразходва дескриптори и тази, която обикновено се изчерпва, е последната.

Започнете със заявка, която можете да възпроизведете, и измерете времето ѝ. Ако TCP ръкостискането завърши, но не пристигне банер на приложението, релеят е взел сокета и после е заседнал в дете или на своя upstream крак. Ако самото ръкостискане никога не завърши, причината е маршрутизация, защитна стена или състояние на слушателя, а не таван на дескриптори. Запишете коя от двете форми сте наблюдавали, защото те сочат към различни процеси.

Пребройте и скоковете, които дублират работа. Разклоняващият се слушател предава всеки приет сокет на дете, което пази свое копие, така че реалната обща бройка е свойство на цялото дърво, не само на родителя.

Прочетете лимита, който релеят е наследил

Единственият лимит, който има значение, принадлежи на работещия процес и е зададен от това, което е стартирало процеса. Писането на 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 спрямо мекия лимит ви показва разликата, а брой с едно-две под тавана е твърд стоп, не бавен път.

Когато броят отказва да падне, гледайте състоянията на сокетите, не общите суми. Дескриптори, стоящи в CLOSE_WAIT, означават, че партньорът е затворил, а вашата страна никога не го е направила, което е дефект в жизнения цикъл на приложението, който по-голям лимит само отлага. Ограничете и модела с деца: разклоняващ се релей без таван на паралелните деца изчерпва дескриптори, процесни слотове и памет заедно.

Проверете новата стойност на живия процес

След редактиране на 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, което е 1024 при типичните сборки, така че таван, вдигнат отвъд това, може да даде откази, които изглеждат несвързани. Справочникът за изпълнение на systemd носи същото предупреждение за услугите, които стартира.

Дръжте рестарта далеч от достъпността на тунела

Рестартирането на релея изпуска активните му сесии и това е отделно събитие от падането на VPN. Подредете промяната така, че тунелът да остане вдигнат, докато релеят се върти, и предупредете всеки, чиято дълготрайна сесия я пресича.

Връщането назад е предишният unit файл плюс още един рестарт и този файл остава на място, докато новата стойност не преживее работен ден. После затворете цикъла със заявката, която първоначално се провали: една нова SSH сесия през релея, един трансфер, достатъчно дълъг, за да има значение, и брой дескриптори, който се връща към нивото си на покой.