رله 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 جدید از طریق رله، یک انتقال به‌قدر کافی طولانی که مهم باشد، و شمارش توصیفگری که به سطح بی‌کاری خود برمی‌گردد.