جدول conntrack: السقف الخفي في شبكات NAT وVPN

في ساعة الذروة تبدأ الشكاوى: المواقع لا تفتح، والتطبيقات تعيد المحاولة، بينما المعالج مرتاح والذاكرة كافية والخط غير ممتلئ. ثم يمر الوقت وتعود الخدمة وحدها. كل المؤشرات المعتادة سليمة، لكن هناك جدولاً واحداً امتلأ بصمت: جدول conntrack.

يشرح هذا المقال ما يفعله الجدول، ولماذا يصبح سقفاً حقيقياً في شبكات NAT وسيرفرات VPN، وكيف تحسب حجمه من حمل شبكتك بدل نسخ رقم كبير من الإنترنت.

ما هو جدول conntrack؟

حين يعمل سيرفر لينكس كبوابة NAT، فإنه يغيّر عناوين الحزم الخارجة، ويجب أن يتذكر كل تحويل حتى يعيد الرد إلى صاحبه. هذه الذاكرة هي جدول تتبع الاتصالات. لكل اتصال سطر فيه العناوين والمنافذ والحالة والمدة المتبقية.

عندما يمتلئ الجدول، لا يستطيع النظام تسجيل اتصال جديد فيرمي حزمته. الاتصالات القائمة تستمر غالباً، أما الجديدة فتفشل. لهذا يقول المستخدم «بعض الأشياء تعمل والباقي لا»، ويبدو العطل عشوائياً.

كيف تعرف أن الجدول هو السبب؟

ثلاثة أوامر تكفي. نفذها وقت المشكلة، لأن القراءة بعد انتهاء الذروة قد لا تكشف شيئاً:

# الاستخدام الحالي والسقف
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

# رسالة الامتلاء في سجل النواة
dmesg -T | grep -i "table full"

# عدّادات الرمي (يتطلب حزمة conntrack)
conntrack -S

إذا اقترب count من max، أو رأيت رسالة nf_conntrack: table full, dropping packet، فقد عرفت السبب. والعدّادات drop وearly_drop تخبرك إن كان النظام يرمي حزماً أو يحذف اتصالات قديمة لإفساح المجال.

كيف تحسب الحجم المناسب؟

لا يوجد رقم صحيح لكل الشبكات. الحساب يبدأ من حملك أنت:

السعة المطلوبة = عدد المستخدمين وقت الذروة × متوسط الاتصالات للمستخدم × هامش أمان

ذاكرة الجدول = السعة المطلوبة × حجم السطر الواحد

لنفترض شبكة وهمية فيها 2,000 مستخدم نشط، وأنك قست متوسطاً قدره 150 اتصالاً لكل مستخدم. الناتج 300,000 اتصال، ومع هامش بمقدار الضعف تصل إلى 600,000. هذه أرقام للتوضيح فقط، والقيمة الصحيحة تأتي من قسمة nf_conntrack_count وقت الذروة على عدد المستخدمين عندك.

حجم السطر يختلف حسب النواة، وهو بضع مئات من البايتات تقريباً. اعرف القيمة الفعلية من النظام نفسه بدل الافتراض:

grep nf_conntrack /proc/slabinfo

بعد الحساب، ثبّت القيمة في ملف إعدادات حتى تبقى بعد إعادة التشغيل. الرقم التالي مثال، فضع الناتج الذي حسبته:

# /etc/modules-load.d/conntrack.conf
nf_conntrack

# /etc/sysctl.d/90-conntrack.conf
net.netfilter.nf_conntrack_max = 600000

ما الذي يملأ الجدول فعلاً؟

ليس كل امتلاء سببه نمو طبيعي. فالسقف الجديد قد يمتلئ أيضاً إن كان السبب جهازاً مصاباً أو إعداداً خاطئاً، وعندها تكون قد أجّلت العطل فقط. افحص هذه الأسباب قبل رفع السقف:

للتمييز بسرعة، احسب أكثر العناوين ظهوراً في الجدول:

conntrack -L -o extended 2>/dev/null \
  | grep -o 'src=[0-9.]*' | sort | uniq -c | sort -rn | head

لا تخلط أيضاً بين هذا السقف وبين نفاد المنافذ. NAT على عنوان عام واحد له حد آخر، لأن عدد المنافذ المتاحة نحو وجهة واحدة محدود. قد يبقى الجدول فارغاً نسبياً وتفشل الاتصالات نحو خدمة شائعة، والحل هنا عناوين عامة أكثر لا جدول أكبر.

أين يوجد الجدول: KVM أم LXC؟

في جهاز KVM لديك نواة مستقلة، فتتحكم في جدولها وسقفه. أما حاويات LXC فتشارك نواة المضيف، والسقف العام يُضبط على المضيف، لذلك قد تتأثر بجيران الحاويات الأخرى. إن كان NAT هو عملك الأساسي فاقرأ المقارنة بين KVM وLXC قبل الاختيار.

وتذكّر أن الجدول جزء واحد من الأداء. المسافة تكلّف عشرات الملّي ثانية، والعتاد الضعيف قد يكلّف آلافاً، فاسأل عن المعالج والتخزين لا عن المدينة وحدها. وعتاد مرام يضم معالجات AMD EPYC 9655 وEPYC 9684X، وراجع صفحة الخدمة لمعرفة مواصفات الباقة التي تهمك.

لمن تناسب هذه الخدمة؟

إن كنت تشغّل NAT أو VPN لعدد كبير من المستخدمين، فأنت تحتاج سيرفراً تتحكم في نواته. يمكنك البدء من سيرفر WireGuard، أو الانتقال إلى سيرفر مخصص إذا كان الحمل كبيراً. هذا يناسب:

• مزوّدي الإنترنت الذين يمررون حركة المشتركين عبر بوابة NAT.
• الشركات التي تربط فروعاً وموظفين عبر خادم واحد.
• المطوّرين الذين يشغلون خدمات تفتح اتصالات كثيرة قصيرة العمر.

أخطاء شائعة

• النظر إلى المعالج فقط: الجدول يمتلئ والمعالج مرتاح تماماً.
• نسخ رقم ضخم: تحجز ذاكرة دون حاجة، ولا تعرف ما الذي يملأ الجدول.
• ضبط القيمة مؤقتاً فقط: تضيع عند إعادة التشغيل ويعود العطل في الذروة التالية.
• خفض المهلات بقوة: تنقطع اتصالات طويلة مشروعة، فغيّرها بالتدريج وراقب.
• القياس صباحاً: القراءة في وقت الحمل الأدنى لا تعبّر عن سقفك الحقيقي.

أسئلة شائعة

هل يملأ WireGuard الجدول بنفسه؟

النفق نفسه لا يضيف سوى أسطر قليلة. الذي يملأ الجدول هو الحركة التي تمر عبره وتخضع لقواعد NAT أو التتبع على الخادم.

هل يبطئ الجدول الكبير الشبكة؟

الجدول الكبير يستهلك ذاكرة، وإن كان عدد مجموعات البحث قليلاً مقارنة بعدد الأسطر فقد يطول البحث. لذلك راجع nf_conntrack_buckets عند رفع السقف كثيراً.

هل يمكنني إلغاء التتبع تماماً؟

يمكن استثناء حركة لا تحتاج NAT أو قواعد حالة، لكن NAT نفسه يحتاج إلى التتبع. طبّق الاستثناء فقط إن فهمت أثره على قواعد الجدار الناري.

الخلاصة

إذا تكررت الأعطال وقت الذروة والمؤشرات المعتادة سليمة، فانظر إلى conntrack. قِس في الوقت الصحيح، وابحث عمّا يملأ الجدول، ثم احسب السقف والذاكرة وثبّت الإعداد. وللمساعدة في اختيار السيرفر المناسب لحمل شبكتك، راجع صفحة الخدمة أو تواصل مع فريق المبيعات.