VPN-aflosser hou op om SSH te aanvaar: lêerbeskrywerbeperkings

’n WireGuard-handdruk voltooi steeds, die eweknie wys steeds ’n onlangse eindpunt, en tog hang ’n nuwe SSH-sessie deur die aflosser agter dit sonder enige banier. Dié kombinasie wys weg van die tonnel en na die proses wat die sok aanvaar. ’n Aflosser soos socat sit in die toepassingspad met sy eie beskrywerbegroting, sy eie kinders en sy eie geërfde limiete. Die wandeling hieronder begin by die kliënt en stop by die eerste komponent wat nie nog ’n sok kan oopmaak nie.

Volg die pad voordat jy ’n nommer verander

Volg een mislukte versoek eerder as om oor die tonnel as geheel te redeneer. Die kliënt skryf in die tonnel, die VPN-daemon ontsyfer en stuur, en die aflosser aanvaar aan die ander kant. Elke stap verbruik beskrywers, en die een wat gewoonlik opraak, is die laaste.

Begin met ’n versoek wat jy kan herproduseer en meet die tyd daarvan. As die TCP-handdruk voltooi maar geen toepassingsbanier kom nie, het die aflosser die sok geneem en dan in ’n kind of op sy stroomopbeen vasgehaak. As die handdruk self nooit voltooi nie, is die oorsaak roetering, ’n vuurmuur of luisteraartoestand eerder as ’n beskrywerplafon. Teken aan watter van die twee vorms jy gesien het, want hulle wys na verskillende prosesse.

Tel ook die spronge wat werk dupliseer. ’n Vurk-luisteraar gee elke aanvaarde sok aan ’n kind wat sy eie kopie hou, so die werklike totaal is ’n eienskap van die hele boom, nie van die ouer alleen nie.

Lees die limiet wat die aflosser geërf het

Die enigste limiet wat saak maak, behoort aan die lopende proses, en dit is vasgestel deur wat daardie proses ook al begin het. Om ulimit -n in ’n dop te tik, beskryf die dop. Vra die diensbestuurder wat dit toegepas het, en bevestig dan op die PID.

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

Die limits-lêer druk sagte en harde plafonne soos die proses hulle sien. ’n Lae sagte waarde onder ’n ruim harde waarde beteken die daemon mag sy eie plafon verhoog, en sommige doen dit met die opstart; gelyke lae waardes beteken die eenheidslêer is die bron.

Drop-ins laai in leksikale volgorde en later lêers wen, so systemctl cat vpn-relay.service is die gesaghebbende siening van wat geld. Om ’n lêer te wysig wat die bestuurder nooit lees nie, is die algemeenste rede waarom ’n verhoogde nommer geen effek het nie.

Skei bestendige gelyktydigheid van behoue toestand

Twee prosesse kan dieselfde plafon tref om onverwante redes, en die remedies verskil. Vraag wat nuttige gelyktydige sessies volg, is ’n kapasiteitsvraag. Groei wat aanhou nadat die werk klaar is, is ’n lek of ’n stel sessies wat niemand toegemaak het nie.

Meet in rus, by jou normale piek, en weer ’n paar minute nadat die las stop. Om oop inskrywings met ls /proc/PID/fd | wc -l teen die sagte limiet te tel, vertel jou die gaping, en ’n telling een of twee onder die plafon is ’n harde stop eerder as ’n stadige pad.

Wanneer die telling weier om te daal, kyk na soktoestande eerder as na totale. Beskrywers wat in CLOSE_WAIT sit, beteken die eweknie het toegemaak en jou kant het dit nooit gedoen nie, wat ’n toepassingslewensiklusfout is wat ’n groter limiet net uitstel. Begrens ook die kindmodel: ’n vurk-aflosser sonder ’n perk op gelyktydige kinders put beskrywers, prosesgleuwe en geheue saam uit.

Kontroleer die nuwe waarde op die lewende proses

Nadat jy die eenheid gewysig het, herlaai die bestuurder en herbegin die diens, want ’n herlaai alleen vervang nooit limiete wat reeds deur ’n lopende proses geërf is nie. Verifieer op die proses wat werklik verkeer bedien.

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

Die awk-reël gee die nuwe paar terug; as dit steeds die ou een wys, is die drop-in wat jy gewysig het nie die een wat gelaai word nie. Die ss-telling is jou werklaskontrole, so maak die aantal sessies oop wat jy verwag en kyk hoe dit klim. ’n Telling wat aanhou styg nadat daardie sessies sluit, beteken die limiet was nooit die hele probleem nie.

Een voorbehoud hoort by enige groot verhoging. Toepassings wat met select() peil, kan nie beskrywers bo FD_SETSIZE dop nie, wat 1024 op tipiese boue is, so ’n plafon wat verby dit verhoog word, kan foute lewer wat onverwant lyk. Die systemd-uitvoeringsverwysing dra dieselfde waarskuwing vir dienste wat dit begin.

Hou die herbegin weg van tonnelbeskikbaarheid

Om die aflosser te herbegin, laat sy aktiewe sessies val, en dit is ’n afsonderlike gebeurtenis van die VPN wat afgaan. Rangskik die verandering so dat die tonnel op bly terwyl die aflosser siklus, en waarsku enigiemand wie se langdurige sessie dit kruis.

Terugrol is die vorige eenheidslêer plus nog ’n herbegin, en daardie lêer bly in plek totdat die nuwe waarde ’n werksdag oorleef het. Sluit dan die lus met die versoek wat oorspronklik misluk het: een nuwe SSH-sessie deur die aflosser, een oordrag lank genoeg om saak te maak, en ’n beskrywertelling wat na sy rusvlak terugkeer.