شناسایی مصرف غیرعادی پهنای باند؛ از لینک تا فرایند

شبکه کند شده و اولین واکنش، درخواست پهنای باند بیشتر است. اما شاید مشکل از یک بکاپ خارج از برنامه، همگام‌سازی ابری، حلقه داخلی یا ارسال دوباره داده باشد. پیش از ارتقای لینک، باید بدانیم فشار از کجا شروع شده، به کجا می‌رود و چه کاری آن را ایجاد می‌کند.

در این مقاله مسیر بررسی را از نمای کلی شبکه تا یک فرایند مشخص دنبال می‌کنیم. مراحل عملی و معیارهای تصمیم، پیشنهاد تحریریه‌اند؛ قابلیت‌ها و محدودیت ابزارها با مستندات اصلی تطبیق داده شده‌اند. هیچ‌کدام از مثال‌ها گزارش آزمایش روی شبکه واقعی خواننده نیست.

اول روشن کنیم «غیرعادی» یعنی چه

ترافیک بالا به‌تنهایی غیرعادی نیست. افزایش موردانتظار هنگام بکاپ، با ارسال مداوم داده در ساعت بدون فعالیت تفاوت دارد. زمان شروع، طول رخداد، جهت انتقال، بخش درگیر و اثر آن بر کاربر را ثبت کنید. مصرف را با ساعت و روز مشابه مقایسه کنید؛ نه فقط با چند دقیقه آرام پیش از حادثه.

نرخ انتقال را با حجم منتقل‌شده اشتباه نگیریم. Mbps نرخ است؛ GB حجم است. در واحد ده‌دهی، 1 MB/s برابر 8 Mbps است. ظرفیت مؤثر لینک سرویس نیز ممکن است از سرعت اسمی پورت کمتر باشد. در لینک Full-duplex، هر جهت را جدا با ظرفیت همان جهت بسنجید؛ جمع ورودی و خروجی به‌تنهایی درصد اشباع یک جهت را نشان نمی‌دهد.

برای هر سؤال، ابزار مناسب را انتخاب کنیم

1. اینترفیس‌ها را با PRTG یا Zabbix زیر نظر بگیریم

از WAN، لینک بین شعب، Uplinkها و رابط‌های مرتبط با سرویس آسیب‌دیده شروع کنید. ورودی و خروجی از دید همان رابط معنا دارند. در PRTG، سنسور SNMP Traffic نقطه شروع است؛ در Zabbix از Template متناسب با دستگاه استفاده کنید و واحد خروجی Item را بررسی کنید.

اگر Item شمارنده تجمعی خامِ Octet برمی‌گرداند، نرخ به اختلاف شمارنده در زمان نیاز دارد؛ در Zabbix این کار با Change per second و تبدیل مناسب واحد انجام می‌شود. روی Itemی که Template قبلاً به bit/s تبدیل کرده، دوباره همان تبدیل را اعمال نکنید. برای شمارنده خام، رابطه زیر است:

bit/s = (counter_now - counter_previous) * 8 / elapsed_seconds

در صورت پشتیبانی، از شمارنده‌های 64-bit استفاده کنید. بازه نمونه‌برداری بلند می‌تواند جهش کوتاه را در میانگین پنهان کند؛ بازه بسیار کوتاه هم هزینه پایش دارد. پیشنهاد ما ثبت نرخ هر جهت همراه با Errors، Discards و Packet rate است. یک آستانه ثابت برای همه لینک‌ها، جای خط مبنای همان لینک را نمی‌گیرد.

PRTG / SNMP · Zabbix / SNMP · Zabbix / Preprocessing

2. دستگاه و مقصد پرمصرف را با NetFlow پیدا کنیم

نمودار رابط می‌گوید کجا شلوغ شده، اما معمولاً نام مصرف‌کننده را نمی‌دهد. اگر تجهیز پشتیبانی می‌کند، NetFlow یا IPFIX را از نقطه مناسب به Collector سازگار بفرستید. در بازه رخداد، مبدأها و مقصدها را بر اساس Bytes و سپس جهت ترافیک بررسی کنید؛ فقط تعداد Session یا Packet را معیار مصرف حجمی نگیرید.

صادرکننده، رابط مشاهده، مسیر قبل یا بعد از NAT، Sampling و زمان‌سنجی Collector را ثبت کنید. در محیط نمونه‌برداری‌شده، تنظیم Sampling باید با صادرکننده هماهنگ باشد و نتیجه را با محدودیت تخمین بخوانید. دیدن یک جریان در چند نقطه به معنی چند بار تولید داده نیست؛ جمع‌کردن کور گزارش همه نقاط می‌تواند دوباره‌شماری بسازد.

پیشنهاد عملی: چند مصرف‌کننده بالای فهرست را به مالک دستگاه، DHCP/IPAM و نقش سرویس وصل کنید. یک IP عمومی پشت NAT یا یک Proxy ممکن است نماینده چند کاربر باشد. Flow معمولاً محتوای رمزگشایی‌شده درخواست را نمی‌دهد؛ برای نسبت‌دادن مصرف به یک کار مشخص، به شاهد برنامه یا میزبان هم نیاز داریم.

Cisco / NetFlow · IPFIX · PRTG / Sampling

3. ترافیک عبوری از FortiGate را در FortiView بررسی کنیم

در FortiView ابتدا بازه زمانی، دستگاه یا VDOM و مسیر مرتبط را درست انتخاب کنید. نماهای Sources، Destinations، Applications و Policies را، در نسخه و امکانات موجود، از همان محدوده دنبال کنید. مرتب‌سازی بر اساس Bytes برای حجم و Bandwidth برای نرخ، سؤال یکسانی را پاسخ نمی‌دهد.

قبل از نتیجه‌گیری از نمودار خالی، پوشش Logging و منبع داده را بررسی کنید. مشاهده تاریخی به لاگ‌های موجود و محل نگهداری آن‌ها وابسته است؛ نبودن داده، نبودن ترافیک را ثابت نمی‌کند. ترافیکی هم که از این فایروال عبور نکرده، در گزارش آن نمایندگی نمی‌شود. تشخیص Application را متناسب با میزان دید ابزار بخوانید.

نام برنامه یا کشور مقصد، به‌تنهایی مجوز مسدودسازی نیست. پیشنهاد ما این است که مبدأ پرمصرف را تا سیاست، مقصد و مالک سرویس دنبال کنیم و پیش از هر محدودیت، اثرش را بر کار ضروری بسنجیم. نام و مسیر منوها با نسخه FortiOS تفاوت دارد؛ این بخش، دستور تغییر تنظیمات فایروال زنده نیست.

FortiView / Monitors · FortiView / Logging · FortiOS / Log settings

4. رفتار انتقال را با Wireshark تحلیل کنیم

وقتی دستگاه و مسیر مشخص شده اما علت هنوز روشن نیست، Capture کوتاه و محدود بگیرید. نقطه ثبت باید ترافیک موردنظر را ببیند؛ روی شبکه سوئیچی، روشن‌کردن Promiscuous mode روی یک رایانه عادی همه Unicastهای دیگر را نشان نمی‌دهد. از نقطه ثبت مناسب، SPAN یا TAP مجاز استفاده کنید. نمونه Capture filter زیر فقط برای یک IP مستندسازی است:

host 192.0.2.25

نشانی نمونه را با مقصد مجاز خود جایگزین کنید. در Statistics، بخش Conversations را بر اساس Bytes و جهت مرور کنید و با I/O Graphs نرخ را روی بازه یکسان ببینید. واحد Bits در یک بازه 1 ثانیه‌ای به تفسیر نرخ کمک می‌کند. دو خط زیر Display filterهای جداگانه‌اند، نه همان Capture filter:

ip.addr == 192.0.2.25
tcp.analysis.retransmission

تعداد Bytes ثبت‌شده الزاماً برابر داده مفید برنامه یا شمارنده WAN نیست. افت Capture، ترافیک تکراری SPAN و نوع نقطه مشاهده می‌توانند تحلیل را منحرف کنند؛ برچسب Retransmission به‌تنهایی اثبات خرابی مسیر نیست. برای دیدن اندازه و الگوی جریان معمولاً نیازی به رمزگشایی محتوای TLS ندارید. فایل Capture را محدود، زمان‌دار و با دسترسی مشخص نگه دارید.

Wireshark / Capture · Conversations · I/O Graphs · Display filters · TCP analysis · Switched Ethernet

5. فرایند پرمصرف ویندوز را با Resource Monitor پیدا کنیم

وقتی مبدأ یک میزبان Windows است، Resource Monitor را باز کنید و به زبانه Network بروید. در فهرست فرایندهای دارای فعالیت شبکه، بر اساس Total، Send یا Receive مرتب کنید؛ سپس همان فرایند را انتخاب و مقصدهای مرتبط را بررسی کنید. اعداد B/sec نرخ بایت هستند؛ آن‌ها را مستقیم با Mbps لینک مقایسه نکنید.

نام فرایند، PID، زمان مشاهده و مقصد را ثبت کنید. مثال PowerShell زیر فقط برای پیوند یک PID نمونه به اتصال‌های TCP همان لحظه است؛ عدد 4321 باید جایگزین شود. این فرمان‌ها نرخ مصرف هر فرایند را اندازه نمی‌گیرند و فهرست کامل ترافیک UDP هم نیستند:

$trafficProcessId = 4321
Get-Process -Id $trafficProcessId
Get-NetTCPConnection -OwningProcess $trafficProcessId |
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State

Resource Monitor نمای همان میزبان است، نه گزارش مصرف اینترنت کل سازمان؛ ترافیک LAN نیز ممکن است در آن دیده شود. TCPView ابزار تکمیلی برای دیدن Endpoint و فرایند مالک است. پیش از بستن یک فرایند، سرویس و کار آن را بشناسید. نام‌هایی مثل System یا svchost به‌تنهایی دلیل بدافزار یا مجوز توقف نیستند.

Microsoft / Resource Monitor · Microsoft / TCPView · Get-NetTCPConnection

6. حلقه شبکه و Broadcast را از دانلود جدا کنیم

اگر LAN به‌هم ریخته ولی مصرف WAN با شدت مشکل هم‌خوان نیست، احتمال مسئله لایه دوم را بررسی کنید. نرخ ورودی Packet، Broadcast و Multicast را در پورت‌های درگیر کنار نقشه اتصال‌ها ببینید. ترافیک داخلی ممکن است هرگز به فایروال اینترنت نرسد.

لاگ تغییر توپولوژی و جابه‌جایی MAC سرنخ‌اند، نه اثبات محل آغاز حلقه. پیشنهاد ما دنبال‌کردن مسیر با نرخ ورودی غیرمنتظره و بررسی آخرین اتصال فیزیکی است. برای آزمون، Uplink ناشناخته را کورکورانه قطع نکنید؛ فقط بخش تأییدشده را با برنامه بازگشت محدود کنید.

Cisco / Layer-2 loops

7. مصرف را با بکاپ و به‌روزرسانی‌ها تطبیق دهیم

زمان شروع ترافیک را با بکاپ، Replication، Cloud sync، توزیع نرم‌افزار و Windows Update تطبیق دهید. این ترافیک می‌تواند مجاز باشد اما در زمان نامناسب یا با سقف نامناسب، سرویس اصلی را تحت فشار بگذارد.

برای Delivery Optimization از گزارش‌ها و ابزارهای تشخیصی خود Windows کمک بگیرید؛ صرف مشاهده یک سرویس مشترک، منبع دقیق مصرف را ثابت نمی‌کند. اقدام پیشنهادی ما، تأیید Job با مالک و آزمون زمان‌بندی یا سقف محدود همان کار است؛ نه خاموش‌کردن دائمی بکاپ و به‌روزرسانی امنیتی.

Microsoft / Delivery Optimization

8. لاگ برنامه را به شواهد شبکه وصل کنیم

اگر یک وب‌سرویس یا API در فهرست مصرف‌کنندگان است، زمان، مسیر درخواست، وضعیت و اندازه پاسخ را در Access log یا لاگ برنامه مقایسه کنید. در NGINX، متغیرهایی مانند $body_bytes_sent به حجم بدنه پاسخ مربوط‌اند؛ شمار درخواست به‌تنهایی حجم مصرف را نشان نمی‌دهد.

پیشنهاد ما ثبت حداقل فراداده لازم و جست‌وجوی دانلود تکراری، Retry پی‌درپی یا پاسخ بزرگ خارج از انتظار است. اندازه ثبت‌شده در لایه برنامه را بدون توجه به فشرده‌سازی و نقطه شمارش، معادل حجم روی لینک ندانید. پیش از نسبت‌دادن رخداد به حمله، شاهد مالک سرویس و الگوی واقعی درخواست را کنار Flow بگذارید.

NGINX / Access logs · NGINX / Variables

یک سناریوی فرضی؛ تماس‌ها کند شده‌اند اما دانلود عادی است

فرض کنیم لینک سرویس 100 Mbps است، ارسال خروجی آن به حدود 90 Mbps رسیده و تماس‌ها اختلال دارند، درحالی‌که دریافت فایل هنوز قابل‌قبول است. ابتدا باید ظرفیت و جهت خروجی را بررسی کنیم؛ سرعت اسمی بالاترِ پورت، این محدودیت سرویس را حذف نمی‌کند.

در این سناریوی آموزشی، Flow یک میزبان با IP نمونه 192.0.2.25 را بالا نشان می‌دهد. FortiView عبور همان ترافیک را در بازه یکسان تأیید می‌کند. روی میزبان، فرایند بکاپ و لاگ Job نیز با زمان رخداد تطبیق دارند. با هماهنگی مالک، سقف همان انتقال را موقتاً کاهش می‌دهیم و تماس و نمودار خروجی را دوباره می‌سنجیم. بهبود پس از این تغییر، شاهد مفیدی است؛ برای نتیجه قابل‌اتکا باید تکرار و هم‌زمانی کارهای دیگر هم بررسی شود.

روال پیشنهادی هنگام حادثه

1. زمان و منطقه زمانی، بخش آسیب‌دیده و معیار تأثیر بر کاربر را ثبت کنید.
2. رابط و جهت شلوغ را با نرخ، خط مبنا و خطاها مشخص کنید.
3. همان بازه را در Flow و فایروال دنبال کنید و مبدأ را به مالک دستگاه برسانید.
4. اگر لازم بود، روی میزبان یا با Capture محدود شاهد تکمیلی بگیرید؛ یک تغییر قابل‌بازگشت انجام دهید.
5. عمل واقعی کاربر و بازگشت نمودارها را تأیید کنید و برای علت پیدا‌شده، مالک و پیشگیری تعیین کنید.

جمع‌بندی؛ مصرف‌کننده بزرگ الزاماً مقصر نیست

پیشنهاد تحریریه این است که به‌جای شکار بزرگ‌ترین عدد، یک زنجیره شاهد بسازیم: رابط، دستگاه، مقصد، فرایند و کار واقعی. وقتی این زنجیره روشن باشد، می‌توان مصرف مجاز اما بدزمان‌بندی‌شده را از انتقال غیرمنتظره، خطای شبکه یا الگوی مشکوک جدا کرد.

مطالعه مرتبط

سرور سالم است، کاربر معطل؛ چرا میانگین سرعت کافی نیست؟