حافظه شبکه فراتر از سوکت برنامه
در یک دروازه Linux ممکن است برنامه مقصد سالم باشد، پردازنده هنوز ظرفیت داشته باشد و با این حال اتصال‌های تازه شکست بخورند. یکی از علت‌های ممکن فشار بر سامانه ردیابی اتصال است. Conntrack بخشی از زیرساخت Netfilter است که اطلاعات جریان‌ها را نگه می‌دارد تا قابلیت‌هایی مانند فیلتر وضعیت‌مند و ترجمه نشانی بتوانند درباره بسته‌ها تصمیم بگیرند. این جدول با فهرست سوکت‌های یک برنامه یکسان نیست. روتر می‌تواند جریان‌های عبوری زیادی را دنبال کند، در حالی که هیچ برنامه محلی مالک سوکت انتهایی آن ارتباط‌ها نیست.
شناخت همین تفاوت مسیر عیب‌یابی را تغییر می‌دهد. خروجی کم‌حجم ss روی یک دروازه الزاماً به معنی کم بودن بار Conntrack نیست. همچنین وضعیت ESTABLISHED در جدول ردیابی را نباید بدون بررسی با وضعیت سوکت در برنامه برابر گرفت. ردیابی از بسته‌هایی که می‌بیند برداشت می‌سازد و به مسیر رفت و برگشت وابسته است. برای تشخیص مشکل باید جایگاه میزبان در مسیر، فضای نام شبکه، قواعد فایروال و وجود NAT مشخص شوند. افزایش یک عدد sysctl پیش از شناخت این تصویر ممکن است فقط زمان بروز دوباره خطا را عقب بیندازد.
یک رکورد نماینده چه چیزی است؟
جریان معمولاً با ترکیبی از نشانی‌ها، درگاه‌ها، پروتکل و جهت ارتباط شناخته می‌شود. Conntrack اطلاعات جهت اصلی و جهت پاسخ را نگه می‌دارد تا بسته‌های برگشتی به جریان مربوط شوند. در NAT ممکن است آدرس و درگاه دیده‌شده در دو سوی دستگاه متفاوت باشند و همین وضعیت نگه‌داری‌شده برای اعمال ترجمه اهمیت دارد. بنابراین پاک کردن رکورد تنها حذف یک سطر آماری نیست؛ می‌تواند دانشی را از بین ببرد که عبور درست بسته‌های بعدی به آن وابسته بوده است.
برای TCP، سامانه ردیابی از مراحل ارتباط و بسته‌های مشاهده‌شده استفاده می‌کند. برای UDP که دست‌دهی TCP را ندارد، مفهوم جریان با قواعد و زمان‌های انقضای متناسب دنبال می‌شود. از این رو تعداد جریان‌های UDP می‌تواند با برنامه‌ای که مقصدهای متعدد را پرس‌وجو می‌کند سریع رشد کند. مشاهده یک عدد کل بدون تفکیک پروتکل و الگوی مقصد، تفاوت یک سرویس DNS پرترافیک، خروجی انبوه به اینترنت و اتصال‌های طولانی کاربردی را پنهان می‌کند. تشخیص درست به ترکیب این اطلاعات نیاز دارد.
شمارش جاری و سقف ظرفیت
در مستندات هسته، nf_conntrack_count شمار رکوردهای جریان تخصیص‌یافته را نشان می‌دهد و خواندنی است. nf_conntrack_max سقف مجاز رکوردها را تعیین می‌کند. نسبت این دو یک شاخص شروع مفید است، اما باید در طول زمان دیده شود. عددی نزدیک سقف که به سرعت رشد می‌کند با همان عدد در وضعیتی پایدار معنای متفاوتی دارد. همچنین افت ناگهانی تعداد ممکن است از پایان طبیعی جریان‌ها، تغییر مسیر، راه‌اندازی مجدد یا عملیات مدیریتی آمده باشد و به تنهایی بهبود واقعی محسوب نمی‌شود.
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_buckets
conntrack -S
این فرمان‌ها برای مشاهده هستند و دسترسی لازم، بارگذاری قابلیت مربوط و نصب conntrack-tools باید وجود داشته باشد. نام و در دسترس بودن برخی شاخص‌ها با محیط هسته و فضای نام شبکه فرق می‌کند. خروجی را همراه زمان، نسخه هسته و نقش میزبان ثبت کنید. اگر در یک container بررسی انجام شود، باید روشن باشد کدام فضای نام مشاهده می‌شود. مقایسه شمارش یک فضای نام با سقف یا ترافیک فضایی دیگر می‌تواند نتیجه نادرست بسازد و تنظیم ظاهراً مؤثر را بی‌ارتباط کند.
چرا تعداد رکورد رشد می‌کند؟
یک برآورد مفهومی مفید این است که تعداد جریان‌های حاضر به نرخ ایجاد جریان تازه و مدت باقی ماندن آن‌ها وابسته است. این رابطه برای فهم رفتار مناسب است، نه محاسبه دقیق همه حالت‌های شبکه. اگر برنامه به جای استفاده دوباره از اتصال، برای هر عملیات ارتباط تازه بسازد، نرخ ورود افزایش می‌یابد. اگر جریان‌ها مدت زیادی بی‌فعالیت باقی بمانند، زمان اقامت بالا می‌رود. هر دو می‌توانند جدول را بزرگ کنند، ولی اصلاح برنامه در حالت اول و بررسی زمان‌های انقضا در حالت دوم مسیرهای متفاوتی دارند.
جهش ترافیک همیشه حمله نیست. راه‌اندازی هم‌زمان تعداد زیادی worker، خطای تلاش دوباره یا قطع یک سرویس مقصد می‌تواند جریان‌های تازه فراوان بسازد. کلاینتی که پس از هر شکست بدون وقفه دوباره وصل می‌شود فشار را تشدید می‌کند. ابتدا هم‌بستگی زمانی با انتشار نسخه، خطای مقصد، تغییر مسیر و تعداد درخواست بررسی شود. اگر علت در حلقه تلاش دوباره برنامه باشد، افزایش ظرفیت جدول ممکن است فرصت تشخیص بدهد ولی سازوکار تولید بار همچنان باقی است. محدود کردن نرخ و فاصله‌گذاری تلاش‌ها باید در لایه مناسب بررسی شود.
Count با Buckets یک عدد نیست
nf_conntrack_buckets اندازه جدول هش را مشخص می‌کند و با سقف جریان‌ها تفاوت دارد. مستندات هسته توضیح می‌دهند که ارجاع‌های جهت اصلی و پاسخ در ساختار جدول درج می‌شوند. در نتیجه رابطه تعداد جریان و طول زنجیره هش را نمی‌توان با فرض یک ورودی ساده برای هر ارتباط توضیح داد. بزرگ کردن max بدون توجه به ساختار جست‌وجو و حافظه ممکن است هزینه پردازش را تغییر دهد. همچنین مقدار buckets در فضای نام اولیه قابل نوشتن است؛ این محدودیت در محیط‌های چندفضایی اهمیت عملی دارد.
برای ظرفیت‌سنجی نباید یک اندازه ثابت حافظه به ازای هر اتصال را از مقاله‌ای قدیمی روی همه هسته‌ها اعمال کرد. امکانات فعال، افزونه حسابداری، نسخه هسته و ساختارهای تخصیص حافظه بر هزینه اثر می‌گذارند. اندازه‌گیری روی همان محیط و بار نماینده ارزش بیشتری دارد. افزایش سقف باید با حافظه آزاد، فشار حافظه هسته و مصرف سایر سرویس‌ها هماهنگ باشد. هدف این نیست که دستگاه تا آخرین بایت جریان بپذیرد؛ باید برای اوج‌های کوتاه، عملیات مدیریتی و بازیابی نیز حاشیه باقی بماند.
زمان انقضا و خطر نسخه عمومی
زمان‌های انقضا بر اساس پروتکل و وضعیت متفاوت‌اند. برای TCP گزینه‌های جداگانه‌ای برای established، syn sent، fin wait و وضعیت‌های دیگر وجود دارد. مقدار طولانی برای جریان برقرار می‌تواند برای ارتباط‌های کم‌ترافیک لازم باشد، اما در برخی الگوها رکوردهای زیادی نگه می‌دارد. کاهش شدید آن بدون شناخت برنامه ممکن است ارتباطی را که هنوز از نظر دو طرف معتبر است از جدول حذف کند. بسته بعدی چنین ارتباطی می‌تواند با قواعد فایروال یا NAT رفتاری غیرمنتظره پیدا کند.
برای تصمیم باید عمر واقعی ارتباط‌ها، فاصله سکوت مجاز و رفتار نگه‌داری اتصال در برنامه ثبت شوند. یک پایگاه داده با اتصال طولانی، تونل مدیریتی و درخواست کوتاه وب نیاز یکسان ندارند. انتخاب یک مقدار کوچک صرفاً برای پایین آوردن count، شاخص را زیبا می‌کند ولی ممکن است خطای کاربردی بسازد. تغییر ابتدا روی نمونه‌ای محدود و با آزمون سکوت، ادامه ارتباط و قطع مسیر انجام شود. تنظیم بازگشت نیز ثبت شود تا در صورت بروز قطع‌های دوره‌ای بتوان علت را سریع به تغییر زمان انقضا مرتبط کرد.
مشاهده جدول و هزینه مشاهده
ابزار conntrack امکان فهرست کردن جریان‌ها، دیدن رویدادها و دریافت آمار را فراهم می‌کند. فهرست کامل روی دستگاهی با تعداد بسیار زیاد رکورد ممکن است خروجی عظیم و هزینه قابل توجه داشته باشد. برای بررسی یک سرویس، فیلتر پروتکل، نشانی یا درگاه مناسب‌تر است. خروجی همچنین اطلاعات ارتباط کاربران را نشان می‌دهد و باید با دسترسی و نگه‌داری متناسب مدیریت شود. ذخیره همه جریان‌ها در یک تیکت عمومی روش مناسبی برای گزارش رخداد نیست؛ خلاصه آماری معمولاً برای شروع کافی است.
conntrack -L -p tcp
conntrack -E
این نمونه‌ها در محیط کوچک آموزشی قابل استفاده‌اند. در محیط عملیاتی، رویداد زنده می‌تواند بسیار پرحجم شود و نبودن یک رویداد در خروجی به تنهایی اثبات نبودن جریان نیست. ظرفیت دریافت و ازدست‌رفتن پیام‌های مشاهده نیز باید در نظر گرفته شود. آمار تجمیعی و شمارش روند را در کنار نمونه محدود به کار ببرید. اگر هدف پیدا کردن منشأ جهش است، توزیع مبدأ، مقصد، پروتکل و عمر رکورد معمولاً پاسخ بهتری از نگاه کردن تصادفی به هزاران سطر می‌دهد.
INVALID و مسیر نامتقارن
وضعیت INVALID الزاماً نشانه حمله نیست. بسته ممکن است با وضعیت شناخته‌شده سازگار نباشد، بررسی checksum را نگذرانده باشد یا بخشی از مسیری باشد که ردیاب همه آن را ندیده است. در شبکه‌ای که رفت از یک دروازه و برگشت از دروازه دیگر عبور می‌کند، هر دستگاه ممکن است تصویر ناقصی داشته باشد. تغییر پارامترهای پذیرش TCP برای حذف علامت خطا بدون بررسی مسیر می‌تواند مسئله اصلی را پنهان کند. ابتدا مسیریابی، توازن بار و محل اعمال NAT باید روشن شوند.
مستندات گزینه‌هایی مانند tcp_loose و tcp_be_liberal را توضیح می‌دهند، اما وجود گزینه به معنی مناسب بودن تغییر آن برای هر خطای شبکه نیست. این تنظیمات روی برداشت ردیاب از بسته‌ها اثر می‌گذارند و باید با سیاست فایروال بررسی شوند. نمونه‌برداری محدود از بسته در دو سمت دروازه می‌تواند نشان دهد کدام جهت یا مرحله ارتباط دیده نمی‌شود. زمان مشترک و فیلتر دقیق در این آزمایش مهم است. تغییر بدون شواهد ممکن است اتصال نمونه را بهتر کند و هم‌زمان منطق کنترل وضعیت کل شبکه را عوض کند.
پاک کردن جدول راه‌حل بی‌هزینه نیست
در رخداد فشار، وسوسه پاک کردن همه رکوردها زیاد است، زیرا عدد فوراً پایین می‌آید. اما حذف وضعیت می‌تواند اتصال‌های جاری، ترجمه نشانی و سرویس‌های حساس را مختل کند. کاهش count پس از چنین عملیاتی گواه رفع علت نیست؛ اگر تولید جریان ادامه داشته باشد، جدول دوباره پر می‌شود. به همین دلیل عملیات حذف گسترده نباید به عنوان اولین فرمان راهنما ارائه شود. تصمیم اضطراری نیازمند شناخت دامنه اثر، مسیر دسترسی مدیریتی و برنامه بازگشت است.
اگر فقط یک جریان یا سرویس معیوب شناسایی شده، اقدام محدود و هماهنگ با مالک آن می‌تواند دامنه اختلال را کاهش دهد. حتی در این حالت باید دانست برنامه چگونه ارتباط را دوباره برقرار می‌کند و آیا عملیات نیمه‌تمام تکرار می‌شود. گاهی مهار منبع تولید جریان یا اصلاح مسیر، نتیجه پایدارتر از دست‌کاری رکوردها دارد. در گزارش رخداد نیز باید بین «کاهش موقت فشار» و «رفع علت» تمایز روشن باشد تا اقدام اضطراری به رویه دائمی و پرخطر تبدیل نشود.
پایش بر اساس زمان باقی‌مانده
هشدار صرفاً بر درصد اشغال می‌تواند دیر یا پرسر‌وصدا باشد. روند رشد، نرخ ایجاد و حذف، خطاهای درج و پیام‌های هسته باید کنار ظرفیت دیده شوند. اگر جدول از نیمه ظرفیت با سرعت زیاد بالا می‌رود، زمان رسیدن به سقف مهم‌تر از عبور از یک درصد ثابت است. در مقابل، سطح بالا ولی پایدار ممکن است با الگوی سرویس سازگار باشد و نیازمند بررسی ظرفیت برنامه‌ریزی‌شده باشد. آستانه‌ها باید با تاریخچه بار همان میزبان تنظیم شوند، نه با یک عدد عمومی.
پذیرش تغییر با آزمون جریان تازه و ارتباط طولانی انجام می‌شود. بار معمول، جهش کوتاه، قطع مقصد و سکوت طولانی را پوشش دهید و هم خطای برنامه و هم شاخص‌های هسته را ثبت کنید. بعد از اصلاح، باید نشان داد مشکل بدون انتقال فشار به حافظه یا قطع ارتباط‌های معتبر رفع شده است. Conntrack زمانی قابل مدیریت می‌شود که آن را حافظه‌ای محدود برای وضعیت شبکه ببینیم؛ نرخ ورود، عمر رکورد، مسیر بسته و ظرفیت سخت‌افزار همگی در رفتار آن نقش دارند و هیچ عدد منفردی جای این مدل را نمی‌گیرد.
