Рэлей VPN перастае прымаць SSH: ліміты дэскрыптараў файлаў

Рукапацісканне WireGuard усё яшчэ завяршаецца, партнёр усё яшчэ паказвае нядаўнюю кропку прызначэння, і тым не менш новая сесія SSH праз рэлей за ім вісіць без банэра. Гэтая камбінацыя паказвае не на тунэль, а на працэс, які прымае сокет. Рэлей накшталт socat стаіць у шляху праграмы з уласным бюджэтам дэскрыптараў, уласнымі даччынымі працэсамі і ўласнымі ўнаследжанымі лімітамі. Ніжэйшае праходжанне пачынаецца ў кліента і спыняецца на першым кампаненце, які не можа адкрыць яшчэ адзін сокет.

Прасачыце шлях, перш чым змяняць лік

Прасачыце адзін няўдалы запыт замест таго, каб разважаць пра тунэль цалкам. Кліент запісвае ў тунэль, дэман VPN расшыфроўвае і маршрутызуе, а рэлей прымае на іншым баку. Кожны крок спажывае дэскрыптары, і той, які звычайна сканчаецца, — апошні.

Пачніце з запыту, які вы можаце ўзнавіць, і замерце яго час. Калі рукапацісканне TCP завяршаецца, але банэр праграмы не прыходзіць, рэлей узяў сокет і затым застрэў у даччыным працэсе або на сваёй верхняй назе. Калі само рукапацісканне ніколі не завяршаецца, прычына — маршрутызацыя, брандмаўэр або стан слухача, а не стол дэскрыптараў. Запішыце, якую з дзвюх формаў вы назіралі, бо яны паказваюць на розныя працэсы.

Падлічыце таксама пераходы, якія дублююць працу. Разгалінаваны слухач перадае кожны прыняты сокет даччынаму працэсу, які трымае ўласную копію, таму рэальная сума — уласцівасць усяго дрэва, а не бацькі аднаго.

Прачытайце ліміт, які ўнаследваў рэлей

Адзіны ліміт, які мае значэнне, належыць працуючаму працэсу, і яго задаў той, хто гэты працэс запусціў. Увод ulimit -n у абалонцы апісвае абалонку. Спытайце службу кіравання, што яна прымяніла, затым пацвердзіце на PID.

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

Файл limits друкуе мяккі і жорсткі столі так, як іх бачыць працэс. Нізкае мяккае значэнне пад шчодрым жорсткім азначае, што дэман мае права падняць свой стол, і некаторыя робяць гэта пры запуску; роўныя нізкія значэнні азначаюць, што крыніца — файл юніта.

Drop-in загружаюцца ў лексічным парадку, і познія файлы перамагаюць, таму systemctl cat vpn-relay.service — аўтарытэтнае ўяўленне пра тое, што дзейнічае. Рэдагаванне файла, які кіраўнік ніколі не чытае, — самая частая прычына таго, што падняты лік не дае эфекту.

Аддзяліце ўстойлівую адначасовасць ад захаванага стану

Два працэсы могуць дасягнуць аднаго столі па несвязаных прычынах, і сродкі розныя. Попыт, які адлюстроўвае карысныя адначасовыя сесіі, — пытанне ёмістасці. Рост, які працягваецца пасля заканчэння працы, — уцечка або набор сесій, якія ніхто не зачыніў.

Мерце ў стане прастою, на звычайнай пікавай нагрузцы і яшчэ раз праз некалькі хвілін пасля спынення нагрузкі. Падлік адкрытых запісаў праз ls /proc/PID/fd | wc -l супраць мяккага ліміту паказвае разрыў, а лік на адзін-два ніжэй за стол — гэта жорсткі стоп, а не павольны шлях.

Калі лік не жадае падаць, глядзіце на станы сокетаў, а не на агульныя сумы. Дэскрыптары ў стане CLOSE_WAIT азначаюць, што партнёр зачыніўся, а ваш бок — не, і гэта дэфект жыццёвага цыкла праграмы, які большы ліміт толькі адкладвае. Абмяжуйце і мадэль даччыных працэсаў: разгалінаваны рэлей без абмежавання адначасовых дзяцей вычэрпвае дэскрыптары, месцы працэсаў і памяць разам.

Праверце новае значэнне на жывым працэсе

Пасля рэдагавання юніта перазагрузіце кіраўнік і перазапусціце службу, бо адна перазагрузка ніколі не замяняе ліміты, ужо ўнаследжаныя працуючым працэсам. Праверце на працэсе, які сапраўды абслугоўвае трафік.

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

Радок awk вяртае новую пару; калі ён усё яшчэ паказвае старую, drop-in, які вы рэдагавалі, не загружаны. Лік ss — гэта ваша праверка нагрузкі, таму адкрыйце чаканую колькасць сесій і назірайце, як ён расце. Лік, які працягвае расці пасля закрыцця гэтых сесій, азначае, што ліміт ніколі не быў усёй праблемай.

З любым вялікім павелічэннем звязана адна засцярога. Праграмы, якія апытваюць праз select(), не могуць назіраць дэскрыптары вышэй за FD_SETSIZE, што складае 1024 у тыповых зборках, таму стол, падняты вышэй, можа даваць адмовы, якія выглядаюць незвязанымі. Даведнік па выкананні systemd нясе тое ж папярэджанне для службаў, якія ён запускае.

Трымайце перазапуск далей ад даступнасці тунэля

Перазапуск рэлея скідвае яго актыўныя сесіі, і гэта асобная падзея ад адключэння VPN. Упарадкуйце змену так, каб тунэль заставаўся ўзнятым, пакуль рэлей цыклічна перазапускаецца, і папярэдзьце кожнага, чыя доўгая сесія перасякае гэта.

Адкат — гэта папярэдні файл юніта плюс яшчэ адзін перазапуск, і гэты файл застаецца на месцы, пакуль новае значэнне не перажыве працоўны дзень. Затым замкніце цыкл запытам, які першапачаткова не ўдаўся: адна новая сесія SSH праз рэлей, адна перадача, дастаткова доўгая, каб мець значэнне, і лік дэскрыптараў, які вяртаецца да ўзроўню прастою.