VPN-relajso ĉesas akcepti SSH: limoj de dosierpriskribiloj

WireGuard-manpremo ankoraŭ finiĝas, la peer ankoraŭ montras lastatempan finpunkton, kaj tamen nova SSH-seanco tra la relajso malantaŭ ĝi pendas sen afiŝo. Tiu kombinaĵo montras for de la tunelo al la procezo, kiu akceptas la ingon. Relajso kiel socat sidas en la aplika vojo kun sia propra priskribila buĝeto, siaj propraj infanoj kaj siaj propraj hereditaj limoj. La suba promenado komenciĝas ĉe la kliento kaj haltas ĉe la unua komponanto, kiu ne povas malfermi alian ingon.

Spuru la vojon antaŭ ol ŝanĝi nombron

Spuru unu malsukcesan peton anstataŭ rezonadi pri la tunelo kiel tuto. La kliento skribas en la tunelon, la VPN-demono malĉifras kaj enkursigas, kaj la relajso akceptas ĉe la fora flanko. Ĉiu paŝo konsumas priskribilojn, kaj tiu, kiu kutime elĉerpiĝas, estas la lasta.

Komencu per peto, kiun vi povas reprodukti, kaj mezuru ĝian tempon. Se la TCP-manpremo finiĝas sed neniu aplika afiŝo alvenas, la relajso prenis la ingon kaj poste blokiĝis en infano aŭ sur sia suprena kruro. Se la manpremo mem neniam finiĝas, la kaŭzo estas enkursigado, fajromuro aŭ aŭskultila stato, ne plafono de priskribiloj. Notu, kiun el la du formoj vi observis, ĉar ili montras al malsamaj procezoj.

Kalkulu ankaŭ la saltojn, kiuj duobligas laboron. Forkanta aŭskultilo transdonas ĉiun akceptitan ingon al infano, kiu tenas sian propran kopion, do la reala sumo estas eco de la tuta arbo, ne de la gepatro sola.

Legu la limon, kiun la relajso heredis

La sola limo, kiu gravas, apartenas al la kuranta procezo, kaj ĝin fiksis tio, kio lanĉis tiun procezon. Tajpi ulimit -n en ŝelo priskribas la ŝelon. Demandu la servoadministrilon, kion ĝi aplikis, poste konfirmu ĉe la PID.

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

La dosiero limits presas la molan kaj malmolan plafonojn tiel, kiel la procezo vidas ilin. Malalta mola valoro sub malavara malmola valoro signifas, ke la demono rajtas levi sian propran plafonon, kaj iuj faras tion ĉe lanĉo; egalaj malaltaj valoroj signifas, ke la unuodosiero estas la fonto.

Drop-in-dosieroj ŝarĝiĝas laŭleksikone kaj postaj dosieroj venkas, do systemctl cat vpn-relay.service estas la aŭtoritata vido de tio, kio validas. Redakti dosieron, kiun la administrilo neniam legas, estas la plej ofta kialo, ke levita nombro havas neniun efikon.

Apartigu stabilan samtempecon de retenita stato

Du procezoj povas trafi la saman plafonon pro senrilataj kialoj, kaj la rimedoj malsamas. Postulo, kiu spuras utilajn samtempajn seancojn, estas demando pri kapacito. Kresko, kiu daŭras post la fino de la laboro, estas liko aŭ aro de seancoj, kiujn neniu fermis.

Mezuru en senaktiveco, ĉe via normala pinto, kaj denove kelkajn minutojn post la halto de la ŝarĝo. Nombri malfermajn erojn per ls /proc/PID/fd | wc -l kontraŭ la mola limo diras al vi la breĉon, kaj nombro unu aŭ du sub la plafono estas malmola halto, ne malrapida vojo.

Kiam la nombro rifuzas malkreski, rigardu ingajn statojn anstataŭ sumojn. Priskribiloj sidantaj en CLOSE_WAIT signifas, ke la peer fermis kaj via flanko neniam faris tion, kio estas difekto de la aplika vivociklo, kiun pli granda limo nur prokrastas. Limigu ankaŭ la infanmodelon: forkanta relajso sen limo pri samtempaj infanoj elĉerpas priskribilojn, procezajn fendojn kaj memoron kune.

Kontrolu la novan valoron ĉe la viva procezo

Post redakto de la unuo, reŝargu la administrilon kaj restartigu la servon, ĉar reŝargo sola neniam anstataŭigas limojn jam hereditajn de kuranta procezo. Kontrolu ĉe la procezo, kiu efektive servas trafikon.

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

La linio awk redonas la novan paron; se ĝi ankoraŭ montras la malnovan, la drop-in, kiun vi redaktis, ne estas tiu, kiu ŝarĝiĝas. La nombro de ss estas via ŝarĝokontrolo, do malfermu la nombron de seancoj, kiun vi atendas, kaj observu ĝin grimpi. Nombro, kiu daŭre kreskas post la fermo de tiuj seancoj, signifas, ke la limo neniam estis la tuta problemo.

Unu averto apartenas al ĉiu granda pliigo. Aplikoj, kiuj enketas per select(), ne povas observi priskribilojn super FD_SETSIZE, kiu estas 1024 ĉe tipaj konstruoj, do plafono levita preter tio povas produkti fiaskojn, kiuj aspektas senrilataj. La systemd-plenumada referenco portas la saman averton por la servoj, kiujn ĝi lanĉas.

Tenu la restartigon for de tunela havebleco

Restartigo de la relajso faligas ĝiajn aktivajn seancojn, kaj tio estas aparta okazaĵo de la malaltiĝo de la VPN. Ordigi la ŝanĝon tiel, ke la tunelo restu supre dum la relajso ciklas, kaj avertu ĉiun, kies longdaŭra seanco trapasas ĝin.

Reverto estas la antaŭa unuodosiero plus alia restartigo, kaj tiu dosiero restas loke ĝis la nova valoro travivos laboran tagon. Poste fermu la buklon per la peto, kiu origine malsukcesis: unu nova SSH-seanco tra la relajso, unu transigo sufiĉe longa por gravi, kaj priskribila nombro, kiu revenas al sia senaktiva nivelo.