Relay-i VPN ndalon pranimin e SSH: kufijtë e përshkruesve të skedarëve

Një handshake WireGuard ende përfundon, peer-i ende tregon një endpoint të fundit, dhe megjithatë një sesion i re SSH përmes relay-it pas tij varet pa asnjë banner. Ky kombinim të largon nga tuneli dhe të drejton te procesi që pranon socket-in. Një relay si socat qëndron në rrugën e aplikacionit me buxhetin e vet të përshkruesve, fëmijët e vet dhe kufijtë e vet të trashëguar. Ecja më poshtë fillon te klienti dhe ndalon te komponenti i parë që nuk mund të hapë një socket tjetër.

Ndiqni rrugën përpara se të ndryshoni një numër

Ndiqni një kërkesë të dështuar në vend që të arsyetoni për tunelin në tërësi. Klienti shkruan në tunel, daemoni i VPN-së dekripton dhe rrugëzon, dhe relay-i pranon në anën tjetër. Çdo hap konsumon përshkrues, dhe ai që zakonisht mbaron është i fundit.

Filloni me një kërkesë që mund ta riprodhoni dhe matni kohën e saj. Nëse handshake-u TCP përfundon, por nuk vjen asnjë banner i aplikacionit, relay-i e mori socket-in dhe pastaj ngeci në një fëmijë ose në këmbën e tij të sipërme. Nëse vetë handshake-u nuk përfundon kurrë, shkaku është rrugëzimi, firewalli ose gjendja e dëgjuesit, jo një tavan përshkruesish. Vini re cilën nga dy format vëzhguat, sepse ato tregojnë procese të ndryshme.

Numëroni edhe hapat që dyfishojnë punën. Një dëgjues që degëzohet i dorëzon çdo socket të pranuar një fëmije që mban kopjen e vet, kështu që totali real është veti e të gjithë pemës, jo vetëm e prindit.

Lexoni kufirin që trashëgoi relay-i

Kufiri i vetëm që ka rëndësi i përket procesit që po ekzekutohet, dhe e ka caktuar ajo që e nisi atë proces. Shtypja e ulimit -n në një shell përshkruan shell-in. Pyetni menaxherin e shërbimit se çfarë zbatoi, pastaj konfirmoni në PID.

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

Skedari limits shtyp tavanet e butë dhe të fortë ashtu siç i sheh procesi. Një vlerë e butë e ulët nën një vlerë të fortë bujare do të thotë që daemoni lejohet të ngrejë tavanin e vet, dhe disa e bëjnë këtë në nisje; vlera të buta të barabarta dhe të ulëta do të thotë që skedari unit është burimi.

Drop-in-et ngarkohen në rend leksikografik dhe skedarët e mëvonshëm fitojnë, kështu që systemctl cat vpn-relay.service është pamja autoritative e asaj që zbatohet. Redaktimi i një skedari që menaxheri nuk e lexon kurrë është arsyeja më e zakonshme pse një numër i ngritur nuk ka efekt.

Ndani njëkohshmërinë e qëndrueshme nga gjendja e mbajtur

Dy procese mund të godasin të njëjtin tavan për arsye të palidhura, dhe mjekimet ndryshojnë. Kërkesa që ndjek sesione të dobishme njëkohëse është çështje kapaciteti. Rritja që vazhdon pas mbarimit të punës është rrjedhje ose një grup sesionesh që askush nuk i mbylli.

Matni në qetësi, në kulmin tuaj normal dhe përsëri disa minuta pasi ndalon ngarkesa. Numërimi i hyrjeve të hapura me ls /proc/PID/fd | wc -l kundrejt kufirit të butë ju tregon hendekun, dhe një numërim një ose dy nën tavan është ndalim i fortë, jo rrugë e ngadaltë.

Kur numri refuzon të bjerë, shikoni gjendjet e socket-eve në vend të totaleve. Përshkruesit që rrinë në CLOSE_WAIT do të thotë që peer-i mbylli dhe ana juaj nuk e bëri kurrë, që është defekt i ciklit të jetës së aplikacionit të cilin një kufi më i madh vetëm e shtyn. Kufizoni edhe modelin e fëmijëve: një relay që degëzohet pa tavan për fëmijët njëkohës shteron përshkruesit, vendet e procesit dhe kujtesën bashkë.

Verifikoni vlerën e re në procesin e gjallë

Pas redaktimit të unit-it, ringarkoni menaxherin dhe rinisni shërbimin, sepse një ringarkim i vetëm nuk zëvendëson kurrë kufijtë që një proces në ekzekutim ka trashëguar tashmë. Verifikoni në procesin që vërtet shërben trafikun.

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

Rreshti awk kthen çiftin e re; nëse ende tregon atë të vjetër, drop-in-i që redaktuat nuk është ai që ngarkohet. Numri i ss është kontrolli i ngarkesës tuaj, prandaj hapni numrin e sesioneve që prisni dhe shikoni si ngjitet. Një numër që vazhdon të ngjitet pasi ato sesione mbyllen do të thotë që kufiri nuk ishte kurrë i gjithë problemi.

Një paralajmërim shoqëron çdo rritje të madhe. Aplikacionet që anketojnë me select() nuk mund të vëzhgojnë përshkrues mbi FD_SETSIZE, që është 1024 në ndërtimet tipike, prandaj një tavan i ngritur përtej kësaj mund të prodhojë dështime që duken të palidhura. Referenca e ekzekutimit të systemd mbart të njëjtin paralajmërim për shërbimet që nis.

Mbajeni rinisjen larg disponueshmërisë së tunelit

Rinisja e relay-it hedh poshtë sesionet e tij aktive, dhe ai është një ngjarje e veçantë nga rënia e VPN-së. Rregulloni ndryshimin që tuneli të mbetet lart ndërsa relay-i qarkullon, dhe paralajmëroni këdo, sesioni i gjatë i të cilit e kalon atë.

Kthimi është skedari i mëparshëm unit plus një rinisje tjetër, dhe ai skedar mbetet në vend derisa vlera e re të mbijetojë një ditë pune. Pastaj mbyllni ciklin me kërkesën që dështoi fillimisht: një sesion i re SSH përmes relay-it, një transferim mjaft i gjatë për të numëruar, dhe një numër përshkruesish që kthehet në nivelin e qetësisë.