محتوای آموزشی وبلاگ نت‌آرام
سایت یا برنامه سرور گاهی باز می‌شود و گاهی اتصال تازه برقرار نمی‌شود. در گزارش کرنل هم پیام
nf_conntrack: table full, dropping packet دیده‌اید. لینوکس برای بعضی قابلیت‌های فایروال و NAT، وضعیت اتصال‌ها را در جدولی نگه می‌دارد. وقتی ظرفیت این جدول پر شود، بسته‌های جدید ممکن است کنار گذاشته شوند و برنامه‌ها خطای timeout بدهند.پرشدن جدول می‌تواند از افزایش طبیعی بار، اتصال‌های بیش از انتظار، تنظیم نامناسب یا ترافیک غیرعادی ناشی شود. هدف فقط بزرگ‌کردن یک عدد نیست؛ باید دلیل رشد را پیدا و پس از رفع، سلامت برنامه را هم امتحان کنید. دستورها در ترمینال سرور لینوکسی با دسترسی مجاز اجرا می‌شوند. برای سرور مجازی ایران یا اختصاصی، اگر SSH ناپایدار است از کنسول ارائه‌دهنده استفاده کنید.
۱. اول مطمئن شوید همان خطا رخ داده است
در سرور دارای systemd، پیام‌های کرنل بوت فعلی را ببینید:
کد / دستورsudo journalctl -k -b --no-pager | grep -i 'conntrack.*table full' | tail -n 30
وجود خط‌های جدید با زمان نزدیک به اختلال، سرنخ قوی است. اگر خروجی خالی بود، ممکن است پیام در بوت قبلی باشد یا ثبت نشده باشد؛ خالی بودن این جست‌وجو به‌تنهایی سلامت همه مسیرهای شبکه را ثابت نمی‌کند. تاریخ و زمان خطا را یادداشت کنید.
اکنون مقدار فعلی جدول و سقف آن را بخوانید:
کد / دستورsysctl net.netfilter.nf_conntrack_count
کد / دستورsysctl net.netfilter.nf_conntrack_max
در یک مثال فرضی، اگر مقدار اول
65530 و سقف 65536 باشد، جدول بسیار نزدیک حد است. این اعداد برای همه سرورها یکسان نیستند. اگر کلید وجود ندارد، پشتیبانی ماژول یا محیط شبکه سرور ممکن است متفاوت باشد؛ بی‌دلیل ماژول یا فایروال را غیرفعال نکنید. در کانتینرها و فضای نام شبکه نیز محدوده‌ای که مشاهده می‌کنید ممکن است با میزبان تفاوت داشته باشد.۲. رشد اتصال‌ها را در چند لحظه مقایسه کنید
این دستور زمان ثبت را نشان می‌دهد:
کد / دستورdate -Iseconds
مقدار
nf_conntrack_count را یک بار یادداشت کنید و یک یا دو دقیقه بعد دوباره بخوانید. اگر تعداد همراه با افت سرویس پیوسته رشد می‌کند، با زمانی که کارها یا بازدید بالا رفته مقایسه کنید. کاهش تعداد بعد از پایان بار می‌تواند طبیعی باشد؛ عدد ثابت یا پایین در زمان بررسی، بروز مشکل در گذشته را رد نمی‌کند.برای خلاصه سوکت‌های خود میزبان:
کد / دستورss -s
این خروجی برای شناخت وضعیت TCP مفید است، اما شمارش سوکت‌های محلی با تمام رکوردهای conntrack یکسان نیست؛ مثلاً ترافیک عبوری یا NAT می‌تواند در جدول باشد. برای دیدن وضعیت‌های TCP محلی:
کد / دستورss -Htan | awk '{print $1}' | sort | uniq -c | sort -nr
تعداد زیاد یک وضعیت سرنخ است، نه اثبات حمله. آن را با نرخ درخواست‌های واقعی و رفتار برنامه مقایسه کنید. برای دیدن سرویس‌های شنونده و پردازش‌های مرتبط:
کد / دستورsudo ss -lntp
خروجی می‌تواند نام و شماره پردازش را نشان دهد. اگر برنامه‌ای اتصال بسیار زیادی می‌سازد، تنظیم connection pool، تعداد پردازش‌ها و سلامت مقصد آن برنامه را بررسی و اصلاح کنید. گزارش اتصال‌ها ممکن است IPهای کاربران را داشته باشد؛ پیش از انتشار عمومی، اطلاعات حساس را حذف کنید.
۳. در صورت وجود ابزار conntrack، آمار را دقیق‌تر ببینید
کد / دستورcommand -v conntrack
اگر مسیر ابزار چاپ شد، می‌توانید آمار ردیاب را بخوانید:
کد / دستورsudo conntrack -S
نام و ساختار شمارنده‌ها با نسخه کرنل و ابزار فرق می‌کند. تغییر شمارنده‌های خطا و دورریزی را در همان بازه با گزارش کرنل مقایسه کنید. اگر ابزار نصب نیست، برای شروع همان
sysctl و گزارش کرنل کافی‌اند؛ نصب بسته روی سرور مشکل‌دار را با سیاست نگهداری خود هماهنگ کنید. از دستورهای پاک‌کردن همه اتصال‌های ردیابی‌شده استفاده نکنید؛ این کار می‌تواند ارتباط‌های فعال و NAT را مختل کند.۴. ظرفیت را فقط با اندازه‌گیری و امکان بازگشت تنظیم کنید
اگر جدول واقعاً به سقف رسیده، بار معتبر است و حافظه کافی دارید، افزایش کنترل‌شده سقف می‌تواند زمان لازم برای رفع علت را فراهم کند. مقدار قبلی را ثبت کنید؛ افزایش بی‌حساب ممکن است حافظه بیشتری مصرف کند و در برابر رشد نامحدود اتصال‌ها درمان دائمی نیست.
برای مثال، فقط اگر مقدار فعلی سرور شما ۶۵۵۳۶ است و ارزیابی منابع افزایش محدود را مجاز می‌داند، مقدار آزمایشی زیر را در همان سرور اعمال کنید:
کد / دستورsudo sysctl -w net.netfilter.nf_conntrack_max=98304
این اعداد نسخه عمومی برای همه سرورها نیستند. تنظیم بالا معمولاً تا ریبوت باقی می‌ماند و روی میزبان مشترک یا محیط مدیریت‌شده باید با مدیر زیرساخت هماهنگ شود. بلافاصله مقدار را بخوانید:
کد / دستورsysctl net.netfilter.nf_conntrack_max
برای بازگشت، همان دستور
sysctl -w را با عدد قبلی ثبت‌شده سرور خودتان اجرا کنید. پیش از کاهش، وضعیت فعلی و تأثیر آن بر ایجاد اتصال تازه را بسنجید. توضیح رسمی پارامتر را در مستندات هسته لینوکس ببینید.اگر پس از چند دوره پایش تصمیم به تنظیم ماندگار گرفتید، یک فایل جدا در
/etc/sysctl.d/ با مقدار تأییدشده ایجاد کنید و قبل از ذخیره بررسی کنید همان گزینه در فایل‌های دیگر یا سامانه مدیریت تنظیمات تعریف نشده باشد. سپس روش بارگذاری و بازگشت را در محیط آزمایشی امتحان کنید. به جای اعمال گروهی همه تنظیمات سیستم، فقط تنظیم مربوط را با برنامه نگهداری خود اعمال کنید.۵. علت اتصال‌های زیاد را رفع کنید
اگر رشد با یک استقرار یا کار زمان‌بندی‌شده شروع شده، تنظیم تعداد اتصال هم‌زمان، timeout و استفاده مجدد از اتصال را در همان برنامه اصلاح کنید و تغییر را با بار واقعی آزمایش کنید. اگر حجم درخواست از منابع غیرمنتظره است، ثبت نمونه‌های محدود لاگ و بررسی آن با مدیر شبکه کمک می‌کند ترافیک معتبر از حمله یا خطای برنامه جدا شود. محدودسازی باید متناسب با همان سرویس و منابع مجاز باشد؛ خاموش‌کردن کل فایروال یا بازکردن همه پورت‌ها مسئله را امن حل نمی‌کند.
اگر افزایش موقت ظرفیت نیز سریع پر می‌شود، اندازه را پی‌درپی چندبرابر نکنید. نسبت ورودی، خروجی، تعداد اتصال‌های جدید و وضعیت RAM را در بازه کوتاه ثبت کنید و در صورت نیاز، برای کنترل ترافیک پیش از رسیدن به سرور با ارائه‌دهنده هماهنگ شوید. یک نمونه لاگ، زمان و مقصد در گزارش بسیار مفیدتر از عبارت کلی «اینترنت قطع است» است.
۶. چطور مطمئن شویم مشکل حل شده؟
در زمان بار معمول، چند بار
nf_conntrack_count و سقف را بخوانید و ببینید جدول مدام به حد نمی‌رسد. گزارش کرنل نباید پیام‌های تازه table full نشان دهد. سپس از یک شبکه مجاز، قابلیت واقعی برنامه مانند ورود یا پاسخ یک درخواست را چند بار آزمایش کنید. نبود خطا در یک دستور، به‌تنهایی سلامت تمام سرویس‌ها را ثابت نمی‌کند.برای اجرای سرویس‌هایی با نیاز به کنترل سیستم‌عامل و شبکه، مشخصات سرور مجازی ایران و در بارهای متناسب با سخت‌افزار مستقل، سرور اختصاصی ایران را با میزان اتصال‌ها و برنامه پایش خود مقایسه کنید.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام