VPN relay prestáva prijímať SSH: limity deskriptorov súborov

Rukovanie WireGuard sa stále dokončí, peer stále ukazuje nedávny koncový bod, a napriek tomu nová relácia SSH cez relay za ním visí bez banneru. Táto kombinácia ukazuje preč od tunela k procesu, ktorý prijíma socket. Relay ako socat sedí v ceste aplikácie s vlastným rozpočtom deskriptorov, vlastnými potomkami a vlastnými zdedenými limitmi. Prechádzka nižšie začína u klienta a končí pri prvej komponente, ktorá nemôže otvoriť ďalší socket.

Prejdite cestu, skôr než zmeníte číslo

Sledujte jednu neúspešnú požiadavku namiesto uvažovania o tuneli ako celku. Klient zapisuje do tunela, VPN démon dešifruje a smeruje a relay prijíma na druhej strane. Každý krok spotrebúva deskriptory a ten, ktorý zvyčajne dôjde, je posledný.

Začnite požiadavkou, ktorú viete zopakovať, a zmerajte jej čas. Ak sa TCP rukovanie dokončí, ale banner aplikácie nepríde, relay vzal socket a potom sa zasekol v potomkovi alebo na svojej upstream nohe. Ak sa samotné rukovanie nikdy nedokončí, príčinou je smerovanie, firewall alebo stav poslucháča, nie strop deskriptorov. Zapíšte, ktorý z dvoch tvarov ste pozorovali, pretože ukazujú na rôzne procesy.

Počítajte aj skoky, ktoré duplikujú prácu. Rozvetvujúci poslucháč odovzdáva každý prijatý socket potomkovi, ktorý si drží vlastnú kópiu, takže skutočný súčet je vlastnosťou celého stromu, nie len rodiča.

Prečítajte limit, ktorý relay zdedil

Jediný limit, na ktorom záleží, patrí bežiacemu procesu a určilo ho to, čo tento proces spustilo. Zadanie ulimit -n v shelli opisuje shell. Opýtajte sa správcu služieb, čo použil, a potom to potvrďte na PID.

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

Súbor limits vypisuje mäkký a tvrdý strop tak, ako ich proces vidí. Nízka mäkká hodnota pod veľkorysým tvrdým stropom znamená, že démon smie zdvihnúť vlastný strop, a niektoré to robia pri štarte; rovnaké nízke hodnoty znamenajú, že zdrojom je unit súbor.

Drop-in súbory sa načítavajú v lexikálnom poradí a neskoršie vyhrávajú, takže systemctl cat vpn-relay.service je autoritatívny pohľad na to, čo platí. Úprava súboru, ktorý správca nikdy nečíta, je najčastejším dôvodom, prečo zvýšené číslo nemá účinok.

Oddeľte ustálenú súbežnosť od zadržaného stavu

Dva procesy môžu naraziť na rovnaký strop z nesúvisiacich dôvodov a nápravy sa líšia. Dopyt, ktorý sleduje užitočné súbežné relácie, je otázka kapacity. Rast, ktorý pokračuje po skončení práce, je únik alebo sada relácií, ktoré nikto nezatvoril.

Merajte v pokoji, na svojom obvyklom vrchole a znova niekoľko minút po zastavení záťaže. Počítanie otvorených záznamov pomocou ls /proc/PID/fd | wc -l proti mäkkému limitu vám povie medzeru a počet jeden alebo dva pod stropom je tvrdé zastavenie, nie pomalá cesta.

Keď počet odmieta klesnúť, pozerajte sa na stavy socketov, nie na súčty. Deskriptory sediace v CLOSE_WAIT znamenajú, že peer zavrel a vaša strana nikdy nie, čo je defekt životného cyklu aplikácie, ktorý väčší limit len odkladá. Obmedzte aj model potomkov: rozvetvujúci relay bez stropu súbežných potomkov vyčerpáva deskriptory, procesné sloty a pamäť spolu.

Overte novú hodnotu na živom procese

Po úprave unit súboru znova načítajte správcu a reštartujte službu, pretože samotné znova načítanie nikdy nenahradí limity, ktoré bežiaci proces už zdedil. Overte to na procese, ktorý skutočne obsluhuje prevádzku.

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

Riadok awk vracia novú dvojicu; ak stále ukazuje starú, drop-in, ktorý ste upravili, nie je ten, ktorý sa načítava. Počet ss je vaša kontrola záťaže, takže otvorte očakávaný počet relácií a sledujte, ako stúpa. Počet, ktorý po zatvorení týchto relácií ďalej rastie, znamená, že limit nikdy nebol celý problém.

Ku každému veľkému zvýšeniu patrí jedna výhrada. Aplikácie, ktoré sa dopytujú pomocou select(), nemôžu sledovať deskriptory nad FD_SETSIZE, čo je pri typických zostaveniach 1024, takže strop zdvihnutý nad to môže spôsobovať zlyhania, ktoré vyzerajú nesúvisle. Referenčná príručka spúšťania systemd nesie rovnaké varovanie pre služby, ktoré spúšťa.

Držte reštart ďaleko od dostupnosti tunela

Reštart relayu zahodí jeho aktívne relácie a to je oddelená udalosť od pádu VPN. Naplánujte zmenu tak, aby tunel zostal hore, kým relay prechádza cyklom, a varujte každého, ktorého dlhá relácia ho pretína.

Vrátenie je predchádzajúci unit súbor plus ďalší reštart a tento súbor zostáva na mieste, kým nová hodnota neprežije pracovný deň. Potom uzavrite slučku požiadavkou, ktorá pôvodne zlyhala: jedna nová relácia SSH cez relay, jeden prenos dosť dlhý, aby mal význam, a počet deskriptorov, ktorý sa vráti na svoju pokojovú úroveň.