Hininto ng VPN relay ang pagtanggap ng SSH: mga limitasyon ng file descriptor

Natatapos pa rin ang isang WireGuard handshake, nagpapakita pa rin ang peer ng kamakailang endpoint, at gayunman nakabitin ang isang bagong SSH session sa relay sa likod nito nang walang banner. Ang kombinasyong iyon ay lumalayo sa tunnel at tumuturo sa prosesong tumatanggap ng socket. Ang relay na tulad ng socat ay nakaupo sa landas ng aplikasyon kasama ang sarili nitong badyet ng descriptor, sarili nitong mga anak at sarili nitong minanang limitasyon. Ang lakad sa ibaba ay nagsisimula sa kliyente at humihinto sa unang bahaging hindi makapagbukas ng isa pang socket.

Sundan ang landas bago baguhin ang isang numero

Sundan ang isang nabigong kahilingan sa halip na isipin ang buong tunnel. Nagsusulat ang kliyente sa tunnel, nagde-decrypt at nagruruta ang VPN daemon, at tumatanggap ang relay sa kabilang dulo. Bawat hakbang ay gumagamit ng descriptor, at ang karaniwang nauubos ay ang huli.

Magsimula sa kahilingang kaya mong ulitin at sukatin ang oras nito. Kung natatapos ang TCP handshake pero walang banner ng aplikasyon na dumarating, kinuha ng relay ang socket at pagkatapos ay naipit sa isang anak o sa upstream na binti nito. Kung ang handshake mismo ay hindi natatapos, ang sanhi ay routing, firewall o estado ng listener, hindi kisame ng descriptor. Itala kung alin sa dalawang anyo ang naobserbahan mo, dahil tumuturo sila sa magkaibang proseso.

Bilangin din ang mga pagtalong nagdodoble ng trabaho. Ang sanga-sangang listener ay nagbibigay ng bawat tinatanggap na socket sa anak na nagtatago ng sarili nitong kopya, kaya ang tunay na kabuuan ay katangian ng buong puno, hindi lamang ng magulang.

Basahin ang limitasyong minana ng relay

Ang tanging limitasyong mahalaga ay pag-aari ng tumatakbong proseso, at ito ay itinakda ng kung ano ang naglunsad ng prosesong iyon. Ang pag-type ng ulimit -n sa isang shell ay naglalarawan sa shell. Tanungin ang service manager kung ano ang inilapat, pagkatapos ay kumpirmahin sa PID.

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

Ang file na limits ay naglilimbag ng malambot at matigas na kisame ayon sa nakikita ng proseso. Ang mababang malambot na halaga sa ilalim ng mapagbigay na matigas na halaga ay nangangahulugang pinapayagan ang daemon na itaas ang sarili nitong kisame, at may mga ginagawa iyon sa pagsisimula; pantay na mababang halaga ay nangangahulugang ang unit file ang pinagmulan.

Ang drop-in ay naglo-load sa leksikograpikong ayos at ang huling file ang nananalo, kaya ang systemctl cat vpn-relay.service ang awtoritatibong tanawin ng nalalapat. Ang pag-edit ng file na hindi binabasa ng manager ay ang pinakakaraniwang dahilan kung bakit walang epekto ang itinaas na numero.

Ihiwalay ang matatag na sabay-sabay mula sa pinanatiling estado

Dalawang proseso ay maaaring tumama sa parehong kisame sa magkaibang dahilan, at magkaiba ang lunas. Ang demand na sumusunod sa mga kapaki-pakinabang na sabay-sabay na session ay usapin ng kapasidad. Ang paglago na nagpapatuloy pagkatapos ng trabaho ay pagtagas o set ng mga session na walang nagsara.

Sukatin sa idle, sa normal na tuktok, at muli ilang minuto pagkatapos huminto ang load. Ang pagbilang ng bukas na entries gamit ang ls /proc/PID/fd | wc -l laban sa malambot na limitasyon ay nagsasabi ng agwat, at ang bilang na isa o dalawa sa ilalim ng kisame ay matigas na paghinto, hindi mabagal na landas.

Kapag ayaw bumaba ng bilang, tingnan ang mga estado ng socket sa halip na mga total. Ang mga descriptor na nakaupo sa CLOSE_WAIT ay nangangahulugang nagsara ang peer at hindi kailanman nagsara ang panig mo, na isang depekto sa lifecycle ng aplikasyon na ipinagpapaliban lamang ng mas malaking limitasyon. Limitahan din ang modelo ng anak: ang sumasangang relay na walang takip sa sabay-sabay na anak ay nauubos ang descriptor, slot ng proseso at memorya nang sabay.

Tiyakin ang bagong halaga sa buhay na proseso

Pagkatapos i-edit ang unit, i-reload ang manager at i-restart ang serbisyo, dahil ang reload lamang ay hindi kailanman pumapalit sa mga limitasyong minana na ng tumatakbong proseso. Tiyakin sa prosesong talagang naglilingkod ng trapiko.

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

Ang linyang awk ay nagbabalik ng bagong pares; kung lumang pares pa rin ang nakikita, ang drop-in na in-edit mo ay hindi ang nilo-load. Ang bilang ng ss ay ang iyong pagsusuri ng load, kaya buksan ang bilang ng session na inaasahan mo at panoorin itong tumaas. Ang bilang na patuloy na tumataas pagkatapos isara ang mga session na iyon ay nangangahulugang hindi kailanman ang buong problema ang limitasyon.

Isang paalala ang kasama ng anumang malaking pagtaas. Ang mga aplikasyong nagpo-poll gamit ang select() ay hindi makapagmamanman ng descriptor na lampas sa FD_SETSIZE, na 1024 sa karaniwang build, kaya ang kisame na itinaas lampas doon ay maaaring gumawa ng mga pagkabigo na tila walang kaugnayan. Ang systemd execution reference ay may parehong babala para sa mga serbisyong sinisimulan nito.

Ilayo ang restart sa availability ng tunnel

Ang pag-restart ng relay ay nagbabagsak ng mga aktibong session nito, at iyon ay hiwalay na pangyayari sa pagbaba ng VPN. Ayusin ang pagbabago upang manatiling up ang tunnel habang umiikot ang relay, at bigyan ng babala ang sinumang may mahabang session na tumatawid dito.

Ang rollback ay ang nakaraang unit file at isa pang restart, at ang file na iyon ay nananatili hanggang ang bagong halaga ay makalampas ng isang araw ng trabaho. Pagkatapos isara ang loop gamit ang kahilingang unang nabigo: isang bagong SSH session sa relay, isang transfer na sapat ang haba upang maging makabuluhan, at bilang ng descriptor na bumabalik sa antas ng idle nito.