VPN-reläet slutar acceptera SSH: gränser för fildeskriptorer

En WireGuard-handskakning slutförs fortfarande, peer visar fortfarande en nylig endpoint, och ändå hänger en ny SSH-session genom reläet bakom det utan banner. Den kombinationen pekar bort från tunneln och mot processen som accepterar socketen. Ett relä som socat sitter i applikationens väg med sin egen deskriptorbudget, sina egna barn och sina egna ärvda gränser. Vandringen nedan börjar hos klienten och stannar vid den första komponenten som inte kan öppna en ny socket.

Följ vägen innan du ändrar ett tal

Följ en enda misslyckad begäran i stället för att resonera om tunneln som helhet. Klienten skriver in i tunneln, VPN-demonen dekrypterar och routar, och reläet accepterar på andra sidan. Varje steg förbrukar deskriptorer, och den som vanligtvis tar slut är den sista.

Börja med en begäran du kan återskapa och mät tiden. Om TCP-handskakningen slutförs men ingen applikationsbanner kommer, tog reläet socketen och fastnade sedan i ett barn eller på sitt uppströmsben. Om själva handskakningen aldrig slutförs är orsaken routing, brandvägg eller lyssnartillstånd, inte ett deskriptortak. Notera vilken av de två formerna du såg, eftersom de pekar på olika processer.

Räkna också hoppen som duplicerar arbete. En forgrenande lyssnare överlämnar varje accepterad socket till ett barn som behåller sin egen kopia, så det verkliga totalet är en egenskap hos hela trädet, inte bara föräldern.

Läs gränsen som reläet ärvde

Den enda gräns som spelar roll tillhör den körande processen, och den sattes av det som startade processen. Att skriva ulimit -n i ett skal beskriver skalet. Fråga tjänstehanteraren vad den tillämpade och bekräfta sedan på PID:en.

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

Filen limits skriver ut den mjuka och den hårda gränsen så som processen ser dem. Ett lågt mjukt värde under ett generöst hårt värde betyder att demonen får höja sitt eget tak, och vissa gör det vid start; lika låga värden betyder att unit-filen är källan.

Drop-in-filer laddas i lexikografisk ordning och senare filer vinner, så systemctl cat vpn-relay.service är den auktoritativa vyn av vad som gäller. Att redigera en fil som hanteraren aldrig läser är den vanligaste orsaken till att ett höjt tal inte har någon effekt.

Separera jämn samtidighet från bevarat tillstånd

Två processer kan nå samma tak av orelaterade skäl, och botemedlen skiljer sig. Efterfrågan som följer användbara samtidiga sessioner är en kapacitetsfråga. Tillväxt som fortsätter efter att arbetet är slut är en läcka eller en uppsättning sessioner som ingen stängde.

Mät i vila, vid din normala topp och igen några minuter efter att lasten stannat. Att räkna öppna poster med ls /proc/PID/fd | wc -l mot den mjuka gränsen visar gapet, och ett antal en eller två under taket är ett hårt stopp, inte en långsam väg.

När antalet vägrar falla, titta på socket-tillstånd i stället för totaler. Deskriptorer som sitter i CLOSE_WAIT betyder att peer stängde och din sida aldrig gjorde det, vilket är ett fel i applikationens livscykel som en större gräns bara skjuter upp. Begränsa också barnmodellen: ett forgrenande relä utan tak på samtidiga barn tömmer deskriptorer, processplatser och minne samtidigt.

Kontrollera det nya värdet på den levande processen

Efter att ha redigerat unit-filen, ladda om hanteraren och starta om tjänsten, eftersom en omladdning ensam aldrig ersätter gränser som en körande process redan ärvt. Verifiera på processen som faktiskt betjänar trafiken.

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

Raden awk returnerar det nya paret; om den fortfarande visar det gamla är drop-in-filen du redigerade inte den som laddas. Antalet från ss är din lastkontroll, så öppna antalet sessioner du förväntar dig och se det stiga. Ett antal som fortsätter stiga efter att dessa sessioner stängts betyder att gränsen aldrig var hela problemet.

En varning hör till varje stor höjning. Applikationer som pollar med select() kan inte övervaka deskriptorer över FD_SETSIZE, vilket är 1024 på typiska byggen, så ett tak höjt förbi det kan ge fel som verkar orelaterade. systemds körningsreferens bär samma varning för de tjänster den startar.

Håll omstarten borta från tunnelns tillgänglighet

Att starta om reläet släpper dess aktiva sessioner, och det är en separat händelse från att VPN:en går ner. Ordna ändringen så att tunneln förblir uppe medan reläet cyklar, och varna alla vars långvariga session korsar den.

Återställning är den föregående unit-filen plus ännu en omstart, och den filen ligger kvar tills det nya värdet har överlevt en arbetsdag. Stäng sedan loopen med begäran som ursprungligen misslyckades: en ny SSH-session genom reläet, en överföring tillräckligt lång för att betyda något, och ett deskriptorantal som återgår till sin vilonivå.