VPN релето престанува да прима SSH: ограничувања на датотечните дескриптори

Ракувањето со WireGuard сѐ уште завршува, peer-от сѐ уште покажува скорешна крајна точка, а сепак нова SSH сесија низ релето зад него виси без банер. Оваа комбинација покажува подалеку од тунелот и кон процесот што го прифаќа сокетот. Реле како socat стои на патеката на апликацијата со сопствен буџет за дескриптори, сопствени деца и сопствени наследени ограничувања. Патувањето подолу започнува кај клиентот и запира на првата компонента што не може да отвори уште еден сокет.

Проследете ја патеката пред да смените број

Проследете едно неуспешно барање наместо да расудувате за тунелот како целина. Клиентот пишува во тунелот, VPN демонот декриптира и насочува, а релето прифаќа на другата страна. Секој чекор троши дескриптори, а оној што обично се троши е последниот.

Започнете со барање што можете да го репродуцирате и измерете го неговото време. Ако TCP ракувањето заврши, но не пристигне банер на апликацијата, релето го зеде сокетот и потоа заглави во дете или на својата горна нога. Ако самото ракување никогаш не заврши, причината е насочување, firewall или состојба на слушачот, а не таван на дескриптори. Забележете кој од двата облика го набљудувавте, зашто тие покажуваат на различни процеси.

Избројте ги и скоковите што ја дуплираат работата. Разгранетиот слушач го предава секој прифатен сокет на дете што чува своја копија, така што вистинскиот вкупно е својство на целото дрво, не само на родителот.

Прочитајте го ограничувањето што релето го наследило

Единственото ограничување што е важно му припаѓа на процесот што работи, а го поставило тоа што го стартувало процесот. Впишувањето 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 значат дека 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, што е 1024 во типични градби, така што таван подигнат над тоа може да создаде грешки што изгледаат неповрзани. Референцата за извршување на systemd го носи истото предупредување за услугите што ги стартува.

Држете го рестартот далеку од достапноста на тунелот

Рестартирањето на релето ги исфрла неговите активни сесии, а тоа е одделен настан од паѓањето на VPN. Наредете ја промената така што тунелот останува горе додека релето циклузира, и предупредете секого чија долготрајна сесија го преминува.

Враќањето е претходната unit датотека плус уште еден рестарт, и таа датотека останува на место додека новата вредност не преживее работен ден. Потоа затворете ја јамката со барањето што првично не успеа: една нова SSH сесија низ релето, еден трансфер доволно долг за да биде важен, и број на дескриптори што се враќа на неговото ниво на мирување.